How Zabbix ticketing integration turns problems into tickets
Zabbix problems usually reach email or chat quickly, but the system of record for incidents is a separate tool, so operators end up copying alerts by hand or missing them. The integration uses Zabbix webhook media types to create, update and close tickets in that system automatically. The targets named for this topic are GLPI, Jira, ServiceNow, Redmine and Zendesk, and each one needs its own media type, its own credentials and its own check before go-live. Teams that already run a ticket queue for on-call work will recognize the gap: the alert exists, but the queue cannot show whether anyone has taken it.
A webhook media type is a script that Zabbix runs when an action sends a notification. When a problem event matches an action, the script receives event data through macros, sends an HTTP request to the target API and returns the ticket identifier to Zabbix. Later events for the same problem, such as an acknowledgment, a severity change or the recovery message, reuse that identifier so the target updates or closes the existing ticket and does not open another. Before building it, confirm exactly where the external ticket ID is stored in your Zabbix version, because the update and close steps depend on finding it again.
The GLPI and Redmine details can be checked against their published documentation. Redmine's REST API must be switched on by an administrator, the issues resource is marked stable, and requests authenticate with a per-user API key sent in the X-Redmine-API-Key header, so the integration should run under a dedicated service user with only the project access it needs. For GLPI, confirm on your installation that the API is enabled, which account the integration will use and which profile rights that account holds for creating and updating tickets. For Jira, ServiceNow and Zendesk, confirm the media type shipped for your Zabbix version and the API version of the target before planning the build.
Version choice affects the plan. Zabbix 7.0 LTS receives full support until 30 June 2027, and Zabbix 7.4 was released on 1 July 2025, so the media types, macros and action settings you build against should match the release you intend to run for the next few years. Plan a test on a non-production target before connecting live alerts, and include a deliberate recovery test, because a missed close is what creates the duplicate and stale-ticket problems that operators notice first. Ask the owner of the ticketing system which fields are mandatory on create, since a rejected request leaves a problem with no ticket unless you check the alert log in Zabbix.
What you need before connecting Zabbix to a ticketing system
Each item below decides whether the Zabbix server can open tickets and close them on recovery. Confirm the Zabbix server and database first, then the ticketing platform version, then the account, network path and certificates that the media type depends on. Check each version against the vendor documentation before you schedule the import.
Zabbix server version and database
Zabbix 7.4 is the release these requirements are checked against. Its server supports MySQL or Percona 8.0.30 to 9.7, MariaDB 10.5 to 12.3, and PostgreSQL 13 to 18, with the TimescaleDB extension 2.13 to 2.29 available on PostgreSQL. Record your exact server version and confirm that your database build falls inside the listed range. The ticketing webhooks run on the Zabbix server, so the server's database and version are the ones to check first.
GLPI version, PHP and database
GLPI 12.0.0 and GLPI 11.x have different runtime requirements, so choose the release line before you install. The README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later. The installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0. Both sources say only MySQL and MariaDB are supported, so plan your database around those two engines and confirm the exact figures for the version you deploy.
Redmine API access and version
An administrator must enable the Redmine REST API before any integration can reach it. The API accepts a per-user API key in the X-Redmine-API-Key header or as a parameter, and core resources such as issues, projects and users are marked stable. Redmine 7.0 runs on Rails 8.1 with Ruby 3.2, 3.3, 3.4 or 4.0 and does not support JRuby. Pick a supported line: 7.0.x receives full support, while 6.1.x receives only bug and security fixes.
Jira and ServiceNow versions
Confirm the release line and deployment model of your Jira or ServiceNow instance against the current vendor documentation before you choose a media type. Cloud and self-managed deployments differ in endpoints, authentication options and administrator steps, so record which one you run. Ask your platform administrator which API user model applies, and note the version in your change request so the webhook configuration matches the API it calls.
Service account with scoped roles
Create a dedicated service identity for Zabbix and keep administrator logins out of the media type. Grant only the project, queue or group rights needed to create, update and close tickets for the categories Zabbix uses. Store the credential in a Zabbix secret macro or your secret store, and set a rotation schedule with your security team. Test the role by creating one ticket before enabling production alerts, and recheck it after each platform upgrade because role names and defaults can change between releases.
Outbound HTTPS and certificate trust
The Zabbix server must open outbound HTTPS connections to the ticketing API, so test the firewall, proxy and DNS path from the server itself, since a workstation test proves little. Zabbix validates the TLS certificate chain on those calls, so install any internal certificate authority in the server's trust store, include intermediate certificates, and confirm that the certificate name matches the URL in the media type. Chain errors usually appear as failed alert deliveries, so review the alert logs after the first test.
How the webhook media types open, update and close tickets
The webhook media types follow a fixed chain of events, and each link depends on the one before it. A trigger evaluates item data and raises a problem event when its expression becomes true. An action whose conditions match that event then runs the media type, and Zabbix passes event macros such as the host name, trigger name, severity, event ID and event time into the script parameters. The media type builds a request and calls the REST API of GLPI, Jira or ServiceNow to open a ticket. When the trigger clears, Zabbix creates a recovery event, and an action with recovery operations runs the media type again so the close path can find the ticket it opened. Confirm the exact macro names and recovery options in the documentation for your installed Zabbix version before you build on them.
The ticket identifier is what keeps this chain from creating duplicates. Zabbix does not manage the ticket for you, so the first run must record the identifier the ticketing system returns and make it findable later. Teams usually place it in an external reference field, a custom field or a label on the ticket, and sometimes also on the Zabbix side, depending on what the media type writes. Every later call, whether a repeated problem event, a severity change or the recovery, should first search the ticketing system for that identifier. If a match exists, the script updates or comments on it. If none exists, it creates a ticket. Without that lookup, action retries, flapping triggers or a second action matching the same event can each open another ticket, and the recovery run has no reliable way to find the one to close.
Decide the edge cases before the first live alert. A ticket may be closed by a person before the recovery event arrives, so the close path must handle an already closed ticket without failing or reopening it by mistake. Decide whether a recovery closes the ticket, adds a comment for the resolving team or moves it to a state your service desk defined, and agree the target states with the ticketing administrators, because they differ across GLPI, Jira and ServiceNow workflows. Plan for API errors, timeouts and rate limits: a failed create must not leave a problem with no ticket, and a failed close must be retried or reported. Ask which service account the script uses and confirm it can search, create, comment and transition tickets, but nothing beyond that.
Verify the chain with controlled tests before relying on it. Use a test host and a trigger you can switch on and off, then confirm that one problem produces one ticket, that repeated evaluations update the same ticket and that the recovery closes it. Flap the trigger deliberately to check the lookup, and try a case where a person has closed the ticket first. Review the Zabbix action log for each run, the event IDs shown in the problem list and the script's own output, which should record the identifier it used. Keep a runbook entry that names the ticket field, the search key and the states the script expects, so the operations team can repair a mismatched ticket without reading the script.
Configuration sequence for Zabbix to GLPI, Jira or ServiceNow
This sequence takes a Zabbix server from a shipped ticketing media type to a verified flow in which problems open tickets and recoveries close them. Each stage ends with a check you can see in both Zabbix and the ticketing system, so faults surface before production hosts are involved. Keep the order, because later steps depend on the credentials and fields configured earlier.
Create the integration account and API credentials
The ticketing administrator creates a dedicated service account for Zabbix, separate from any personal login, and grants it rights only to create and update tickets in the target project, queue or workspace. Generate the API credential the chosen platform requires and confirm with its vendor documentation whether an administrator must first enable its API interface. Store the secret in your secrets tooling, not in a shared note. Done means a direct API request from the Zabbix server, using only these credentials, lists the expected project or queue, and a request for an object outside the account's rights is refused.
Import or install the media type in Zabbix
A Zabbix administrator opens the media types section in the web interface and confirms that the GLPI, Jira or ServiceNow media type is present. If it is not, import the file that matches your Zabbix release from the official distribution, and check that the version on your server is one the vendor supports. Review the parameter list before changing anything, since the names and required fields differ between platforms. Done means the media type appears in the list, is enabled, and shows the parameter fields you expect to fill in.
Set media type parameters and send a test message
Enter the base URL, the credential from step one, the target project or queue, and the issue type or category, then map Zabbix severities to the priority or urgency values your ticketing team uses. Use the test function in the media type form to send a manual message with a sample subject and body. Done means a test ticket appears in the ticketing system with the expected title, description, priority and project. If it does not, read the entries the test writes to the Zabbix server log before changing other settings.
Create a user media entry for the integration user
Create a dedicated Zabbix user for ticket creation, give it read access to the host groups it will alert on, and avoid granting it administrative rights. Add a media entry that points to the configured ticketing media type and enter the recipient value the media type expects, such as a project key or queue identifier, as documented for that platform. Set the severity filter to match the events this user should ticket. Done means sending a test from the user's media entry creates one ticket, and the entry shows as enabled with the intended severities selected.
Build a trigger action for problem and recovery events
In the trigger actions section, create an action with conditions that match the host groups and severities in scope. Add an operation that sends the problem message to the integration user, then add a recovery operation that sends the recovery message to the same media type, so the ticket is closed on resolution. Include the event ID or a similar correlation value in the message so later updates reference the original ticket. Avoid a second action that sends the same problems to the same queue. Done means a problem event opens exactly one ticket, and the recovery event is recorded against that ticket.
Run a controlled test on a non-production host
Choose a non-production host and create a controlled condition that triggers a known problem, such as stopping a test service or temporarily lowering a threshold on a test item. Let the problem open, confirm the ticket fields, then restore the condition and watch the recovery. Repeat the trigger once to check for duplicate tickets. Done means one ticket carries the expected severity, fields and correlation value, its history shows the recovery update or closure, and the Zabbix event log matches. Only then extend the action to production host groups.
Mapping Zabbix severity, hosts and events to ticket fields
This table compares how Zabbix problem and recovery data can land in GLPI, Jira, ServiceNow or Redmine fields. Read each row as a question to answer in the target instance: the Zabbix side is fixed, while the ticket side is either free text or an enumeration that you must confirm before building the media type. The main takeaway is that severity, group and status mappings must be built and tested separately for each instance, since no platform inherits them from Zabbix.
| Zabbix value | Ticket target | Field type | What to confirm |
|---|---|---|---|
| Trigger severity (not classified to disaster) | Priority or urgency | Enumeration, values differ per platform | Map all six levels to the priority or urgency list that exists in your instance |
| Host name | Ticket title or description | Free text | Confirm the title length limit and use a consistent pattern so tickets can be searched |
| Host group | Category, assignment group or team | Enumeration or lookup, platform-specific | Confirm which groups exist and who owns each one in GLPI, Jira, ServiceNow or Redmine |
| Problem event ID and trigger ID | External reference or custom field | Free text or custom field | Confirm a field that accepts text and that the ID can be searched from the ticket view |
| Recovery event | Status transition to closed or resolved | Enumeration of workflow states | Confirm the exact closing state name and whether it requires a resolution or closure code |
| Trigger name and problem description | Ticket description | Free text | Confirm how much macro text is kept and that the field does not truncate long alert bodies |
| Issue or ticket type | GLPI ticket type, Redmine tracker, Jira issue type or ServiceNow incident class | Enumeration, not shared across platforms | GLPI ticket fields and Redmine issue fields differ from Jira issue types and ServiceNow incident fields, so confirm each value |
Securing the Zabbix to ticketing connection
The Zabbix to ticketing connection depends on an integration account, stored credentials, a media type script, a network path and two sets of logs. Each card below covers one of these controls, and together they determine who can change how alerts become tickets, what can reach the ticketing API and whether the trail can be followed afterward. Review them before the first production alert and again after any change to Zabbix or the ticketing platform.
Dedicated least-privilege integration account
Create a separate Zabbix user and a separate GLPI, Jira or ServiceNow account for the alert flow, and do not reuse an administrator login. Limit the account to creating and updating tickets, and to reading only the fields the media type needs. In GLPI 12.0.0, active sessions can be viewed and revoked, and certain administrative actions require step-up authentication, so decide whether this account is exempt from those prompts or stays under the same governance as human administrators. Confirm the exact permissions your ticketing version requires before granting them.
Storing and rotating API tokens
The webhook needs a token or password to reach the ticketing API. Keep it in a secret macro or in the secret store your team already operates, and confirm which option your Zabbix version supports for media type parameters. Avoid pasting tokens into the script body, where anyone who can read the media type can see them. Set a rotation interval, rotate on staff changes, and test that the alert flow still creates tickets after each change.
Restricting who edits media type scripts
The webhook media type contains the JavaScript that builds each ticket request, and it runs on the Zabbix server or proxy that sends the alert. Limit edit rights on the media type to a small named group, and keep the integration team's Zabbix roles separate from general operators. Store the script in version control and review each change before it is imported. Confirm who can view the script as well, since it reveals endpoints and parameter names even when tokens are kept as secrets.
TLS verification for the ticketing endpoint
Point the webhook at the HTTPS address of the ticketing service and keep certificate verification enabled. If your GLPI, Jira or ServiceNow instance uses an internal certificate authority, add that CA to the trust store of every Zabbix server and proxy that sends alerts, and avoid disabling verification to get past a certificate error. Agree the accepted protocol and cipher policy with your security team. In a non-production environment, test an expired certificate and one from an unknown CA to confirm that the failure is logged and no ticket is created.
Network path rules from server or proxy
Allow outbound HTTPS only from the Zabbix server or the proxy that runs the webhook, to the ticketing hostname and port, and deny other sources. If alerts are sent from a proxy group, every proxy in the group needs the same path, because monitored hosts can move between proxies when one goes offline. Route traffic through an egress proxy only if your policy requires it, and confirm that the proxy setting applies to the media type. Record the rule with an owner so firewall changes do not silently stop alerting.
Audit logging on both sides
Record activity in Zabbix and in the ticketing system, then match the two. In Zabbix, review the audit log for media type changes and user or role changes, and check the action log for notifications sent. In the ticketing tool, review the audit or event log for tickets created or updated by the integration account, and for sessions revoked in GLPI 12.0.0. Forward both logs to your central log platform and test that a sample alert appears in each with a shared reference so an incident can be traced end to end.
Duplicate tickets, missing recoveries and other common failures
This table lists the failures teams most often hit when Zabbix sends problems to GLPI, Jira, ServiceNow or Redmine, with the likely cause and the layer where each fix belongs. Read each row from the symptom to the layer it names, starting with Zabbix actions for duplicate tickets and tickets that never close. Most failures sit in the action or in the ticketing system's own settings, so check those before changing the media type.
| Failure | Likely cause | Fix at the affected layer |
|---|---|---|
| Duplicate tickets | Each new problem event creates a ticket because the ticket reference is not stored or checked before another creation | In the Zabbix action, create a ticket only for the first problem event and reuse the stored ticket reference for later updates |
| Tickets stay open | No recovery operation is configured in the action, or the stored reference is lost, so the close call has no ticket to target | Add a recovery operation to the action, then confirm the reference persists through escalations and re-opened problems |
| Authentication errors | Expired or revoked API token, a service account without the needed role, or a call to an API version the target does not expose | Check token expiry and the account's role in the ticketing system, then confirm the endpoint version in the media type matches the target |
| TLS errors | Private certificate chain not trusted by the Zabbix server or proxy that sends the webhook request | Add the internal root and intermediate certificates to the trust store used by the sending host, and confirm the hostname matches the certificate |
| GLPI API path blocked | Web server document root points to the installation root, or URL rewriting does not route requests through index.php | Point the document root to GLPI's public directory, enable URL rewriting in your web server, then test the API path directly |
| Redmine API unavailable | The REST API is disabled by a Redmine administrator, so API requests fail | Ask a Redmine administrator to enable the REST API, then test with a per-user API key sent in the X-Redmine-API-Key header |
| Every alert at top priority | Severity mapping leaves the priority fixed or maps all Zabbix severities to the highest ticket priority | Map each Zabbix severity to its own ticket priority in the media type or action logic, and test each level with a sample problem |
Choosing between GLPI, Jira, ServiceNow, Redmine and Zendesk as the ticket target
Choose the ticket target by the system your responders already work in. Zabbix sends each problem to a webhook media type, so the practical question is whether an existing queue, asset register and approval flow can receive those tickets without a second tool. Before you compare, list the platforms your service desk, platform team and change process already run, and note who holds the administrator rights needed to create the integration user, the custom fields for severity and host reference, and the API credentials. The five candidates differ mainly in what they bring with them: GLPI brings assets and a CMDB, Redmine brings a project-oriented issue tracker, and Jira, ServiceNow and Zendesk bring workflows your organization may already have bought.
GLPI is an open-source IT service management platform with tickets, assets, a CMDB, contracts and financial management. It fits best where the team already keeps hardware and software inventory in GLPI, because a Zabbix problem can then point to the same asset record the service desk uses. Check the version line before you plan the host. The README lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the installation docs for GLPI 11.0 list PHP 8.2 with MariaDB 10.6, so confirm which line your deployment targets. For self-hosting, the recurring cost is hosting and staff time. GLPI Network is a separate paid service: the GLPI subscriptions page lists 19 euros per user per month for public cloud and 21 euros per user per month for private cloud with a 25-user minimum, and self-hosted subscriptions from 100 euros per month (Basic) to 4,500 euros per month (Enterprise).
Redmine is a Ruby on Rails issue tracker and project management application released under GPL v2. It has no paid edition, so its cost is hosting, plugins, upgrades and the people who run it. Its REST API supports JSON and XML, but an administrator must enable it first. Calls authenticate with HTTP basic authentication or a per-user API key sent in the X-Redmine-API-Key header, so give the integration a dedicated user with only the project permissions it needs. Issues, projects, users and time entries are marked stable in the API documentation. Redmine has no built-in CMDB, so decide whether severity, host and problem ID will live in custom fields. Redmine 7.0.x is the fully supported line. Confirm your database choice against its requirements: PostgreSQL, MySQL 8.0 to 8.4 with READ COMMITTED isolation, or SQL Server 2012 or higher. SQLite is not suited to multi-user production use.
Jira, ServiceNow and Zendesk are commercial platforms, so license tier, paid user counts and API access are set by your own contracts. Confirm them with each vendor before design starts. Ask whether the integration account needs a paid seat, which API rate limits apply to your expected alert volume, and whether your plan includes the workflow transitions you need when a problem recovers. No supplied fact covers Zendesk's API or plan terms, so treat its details as open items to confirm. The recurring cost on these platforms is the subscription, while your own costs are the integration build, testing and maintenance after vendor upgrades. Request quotes that separate subscription, add-on and API access charges, and agree in writing who owns the webhook script and its credentials after handover.
Questions buyers ask before outsourcing Zabbix ticketing work
How much does it cost to connect Zabbix alerts to GLPI, Jira or ServiceNow?
The cost comes from the work scope and the ticketing platform, not from Zabbix itself. Zabbix states its open source software has no license fee, no device limits and no feature gates. The ticketing platform is usually the largest recurring line. For GLPI, the GLPI Network subscriptions page lists public cloud at 19 euros per user per month and private cloud at 21 euros per user per month with a 25-user minimum. Self-hosted GLPI Network subscriptions range from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise). Implementation effort is a one-time cost. Ask any quote to separate the one-time build from recurring items such as subscriptions, hosting and maintenance, and to state which ticketing edition or tier it assumes.
Do we need a paid Zabbix support subscription for a ticketing integration?
No. The integration works on the open source Zabbix server, and a paid support subscription is optional. If you want one, Zabbix offers Silver, Gold, Platinum, Enterprise and Global tiers. Silver provides 8x5 support with a 1 day response time, and Gold provides a 4 hour response time. Platinum provides 24x7 support with a 2 hour response time, Enterprise a 1.5 hour response time and Global a 1 hour response time. Choose a tier based on how quickly your operations team needs help when alert routing breaks, and confirm the exact hours and terms with Zabbix before you rely on them.
Can our own team build the Zabbix ticketing integration without a partner?
Often yes, if you have the right skills in-house and the time to test properly. The work needs someone who administers Zabbix actions and media types, someone who knows the ticketing platform's API, custom fields and workflows, and someone who can test failure paths. Redmine, which is also one of the shipped media types, has no paid edition, so its cost comes from hosting, implementation, plugins, upgrades and the people who maintain it. A partner makes sense when those skills are scarce or when you need a fixed scope agreed in writing before work starts. Decide based on who will own the integration after launch.
What drives the effort of mapping Zabbix severity to ticket priority?
Four factors drive most of the effort. The first is the number of trigger actions, since each rule that creates or updates a ticket needs its own conditions, tests and owner. The second is mapping complexity, such as converting Zabbix severities, host groups, tags and recovery events into ticket priorities, categories, assignment groups and templates. The third is the ticketing platform's customization, including required fields, custom forms, workflow rules and approval steps. The fourth is the testing required to prove each path works, including escalations and maintenance periods. Ask for an inventory of actions and mappings in the scope, because that list sets most of the estimate.
How do we prevent duplicate tickets when Zabbix problems recover?
The integration must store a stable reference to each Zabbix problem in the ticket, then use that reference to decide whether to create, update or close a ticket. When a recovery event arrives, the matching ticket should be closed or moved to a resolved state rather than a new ticket being opened. Designs must also handle flapping triggers, repeated updates during an outage and escalations that reopen a closed problem. Test each path with controlled triggers in a non-production instance and confirm that the external identifier survives ticket edits and API retries. Document which events create tickets and which only add comments.
What should our engineers check in GLPI before connecting Zabbix?
Start with the version and its runtime requirements, because the requirements differ between sources. The GLPI README on the main branch lists PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later, while the installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0. Confirm the target version with Teclib' before you build. Check that the web server document root points to GLPI's public directory, that an API user and client are set up, and that authentication order (database, LDAP, IMAP and others) suits your directory. After any update, plugins are suspended and must be reactivated after major updates, so include that step in your test plan.
What does our organization need to provide for an outsourced ticketing integration?
Before work starts, prepare named owners for Zabbix, the ticketing platform and the approvals, plus access to a non-production Zabbix server and ticketing instance. Provide administrative or API credentials for each system, and a current list of trigger actions, severity levels, host groups, assignment groups and ticket categories. Share the ticketing platform's custom fields, workflows and required values, and the escalation rules your service desk already uses. Agree on a test window, the production change process and who signs off test results. A fixed-scope agreement should list these inputs and what happens if they change.
How DeployOpen scopes, builds and supports the ticketing integration
DeployOpen approaches Zabbix alerts to ticketing with GLPI, Jira or ServiceNow as a fixed-scope implementation inside your own infrastructure. We start from the ticket platform you run, the Zabbix version and the alert rules your teams need, then agree the deliverables in writing before work starts. Documentation and handover are part of the work, and ongoing support is available as a retainer.
How we scope
- The written scope names the ticket platform, its version and hosting model, and who owns each side.
- It lists which Zabbix problems open tickets, which severities map to which priorities, and which events are excluded.
- Engagements are fixed-scope, and ongoing support is available as a retainer once the work is handed over.
How we build
- We configure the Zabbix media type and action logic for the chosen platform in a test environment first.
- Test cases cover opening a ticket, updating it on escalation, closing it on recovery and suppressing duplicates.
- Ticketing API credentials are kept in a secrets store you control, and rotated under your change process.
How we hand over
- Handover includes the exported Zabbix configuration, the media type settings and a runbook for the on-call team.
- The runbook explains duplicate handling, how tickets close on recovery and how to add a new alert source.
- Your team receives a walkthrough of the ticket fields and the mapping table before acceptance.
How we support
- Support can cover upgrades of Zabbix, GLPI, Jira or ServiceNow connectors and changes to alert rules.
- Changes to ticket platform versions are tested against the integration before they reach production.
- Ask each vendor, or the compatibility notes they publish, which versions your integration supports.
