Introduction

Zabbix ServiceNow integration connects infrastructure monitoring with IT service management so that technical events detected by Zabbix can be converted into actionable ServiceNow events or incidents. Instead of asking operations teams to monitor Zabbix continuously and manually create ServiceNow tickets, the integration can automate event collection, incident creation, updates, recovery processing, and configuration-item association.

In a typical enterprise environment, Zabbix monitors servers, databases, applications, network devices, and other infrastructure components, while ServiceNow manages incidents, configuration items, service operations, and IT workflows. ServiceNow currently provides a Zabbix connector for Event Management, while Zabbix also provides a ServiceNow webhook for creating ServiceNow incidents from Zabbix events.

The important implementation decision is therefore not simply “How do I connect Zabbix to ServiceNow?” The real question is:

Should Zabbix events be consumed by ServiceNow Event Management, or should Zabbix directly create incidents through the ServiceNow API?

That distinction has a major impact on architecture, deduplication, CI mapping, recovery handling, and operational support.

What Is Zabbix ServiceNow Integration?

Zabbix is generally used to detect infrastructure and application conditions such as:

• CPU utilization exceeding a threshold

• Memory exhaustion

• Disk-space problems

• Database availability issues

• Network failures

• Application process failures

• HTTP response-time degradation

• Server availability problems

• Custom application monitoring conditions

ServiceNow, on the other hand, can provide the operational workflow around those events.

A simplified architecture looks like this:

Zabbix
   |
   | Monitoring Event
   v
Integration Layer
   |
   +------------------------+
   |                        |
   v                        v
ServiceNow Event        ServiceNow Incident
Management              Management
   |
   v
CI / Service Mapping
   |
   v
Assignment / Workflow
   |
   v
Support Team

There are two important integration patterns.

Zabbix’s current integration documentation supports a ServiceNow webhook and documents configuration for Zabbix 7.4, including ServiceNow credentials, urgency mapping, recovery processing, and custom fields.

Zabbix Webhook vs ServiceNow Zabbix Connector

This is one of the first decisions an integration consultant should make.

Zabbix Webhook

The Zabbix webhook is useful when the requirement is straightforward:

“When a Zabbix trigger becomes a problem, create a ServiceNow incident.”

Zabbix’s webhook supports problem, recovery, and update processing for trigger-based events. It can also populate ServiceNow custom fields.

The basic flow is:

Zabbix Trigger
      |
      v
Zabbix Action
      |
      v
ServiceNow Webhook
      |
      v
ServiceNow REST API
      |
      v
Incident

ServiceNow Event Management Connector

The ServiceNow connector is more appropriate when the organization wants Zabbix to participate in Event Management.

The connector collects events from Zabbix and can use Event Management functionality for event processing and operational workflows. ServiceNow’s current documentation describes configuring the Zabbix server connector through Event Management → Integrations → Connector Instances and supports MID Server selection.

The architecture becomes:

Zabbix
   |
   v
Zabbix Connector
   |
   v
MID Server
   |
   v
ServiceNow Event Management
   |
   +--> Event Rules
   +--> CI Binding
   +--> Alert Processing
   +--> Incident Creation

A ServiceNow Community discussion also highlights this distinction: the Zabbix webhook documentation is aimed at creating incidents, while ServiceNow Event Management uses the Zabbix pull connector to retrieve events.

Real-World Zabbix ServiceNow Integration Use Cases

Use Case 1 – Production Server CPU Alert

Consider an enterprise application server:

Server: APP01
CPU Threshold: 90%
Current CPU: 97%

Zabbix detects the condition and generates a problem event.

Instead of sending an email to the infrastructure team, the integration creates an operational event or incident in ServiceNow.

Example incident data:

The support team receives the ticket in ServiceNow while Zabbix remains the monitoring source.

Use Case 2 – Database Availability Failure

Suppose Zabbix monitors an Oracle database.

A database listener stops responding.

Zabbix detects:

Oracle DB PROD01
Listener Status = Down

The event is transferred to ServiceNow.

The ServiceNow workflow can then:

1. Identify the CI.

2. Determine the assignment group.

3. Create or update an alert.

4. Create an incident if required.

5. Notify the DBA team.

6. Track resolution.

7. Close or update the incident when the monitoring condition recovers.

This is particularly useful in environments where monitoring and IT service management are handled by different teams.

Use Case 3 – Automated Recovery

Suppose Zabbix creates an incident when an application becomes unavailable.

At 10:15:

Problem detected
Application: PAYROLL-API
Status: DOWN

At 10:22:

Recovery detected
Application: PAYROLL-API
Status: UP

A properly designed integration should correlate the recovery with the original event instead of creating a second unrelated record.

This is one reason event correlation and stable event identifiers are important.

Architecture and Technical Flow

A production architecture should normally contain the following layers.

Layer 1 – Monitoring

Zabbix detects the technical condition.

Example:

Trigger:
{APP01:system.cpu.util.last()}>90

The trigger generates a problem event.

Layer 2 – Event Filtering

Not every monitoring event should become a ServiceNow ticket.

For example:

CPU > 90% for 5 minutes → Create incident
CPU > 80% for 30 seconds → Do not create incident
Informational event → Event only
Critical database failure → Incident

This filtering should happen as close to the monitoring source as practical.

Layer 3 – Transformation

The integration transforms Zabbix information into the ServiceNow structure.

Example:

Zabbix Severity: Disaster
        ↓
ServiceNow Urgency: 1

Zabbix Severity: High
        ↓
ServiceNow Urgency: 2

Zabbix’s current ServiceNow webhook documentation includes configurable urgency values for different Zabbix severities.

Layer 4 – ServiceNow Processing

ServiceNow receives the event or incident and performs operational processing:

Event
 ↓
Alert
 ↓
CI Association
 ↓
Correlation
 ↓
Incident
 ↓
Assignment
 ↓
Resolution

Where Oracle Integration 3 Fits

Zabbix and ServiceNow do not necessarily require Oracle Integration 3.

If the requirement is simply:

Zabbix → ServiceNow

the native Zabbix webhook or ServiceNow connector may be sufficient.

However, Oracle Integration 3 becomes useful when ServiceNow is part of a larger enterprise integration landscape.

For example:

Zabbix
   |
   v
ServiceNow
   |
   v
Oracle Integration 3
   |
   +---- Oracle Fusion HCM
   +---- Oracle Fusion ERP
   +---- Oracle Fusion SCM
   +---- OCI
   +---- Email / REST APIs

Oracle Integration 3 provides a ServiceNow Adapter that can operate as either a trigger or invoke connection. The adapter supports REST and SOAP endpoints, CRUD operations, queries, attachments, and several authentication mechanisms.

For example, an enterprise might have this requirement:

When a critical infrastructure event affects a server hosting an Oracle business application, create the ServiceNow incident and send selected operational information to an Oracle Fusion or OCI process.

In that situation, OIC can perform:

• Data transformation

• Routing

• Conditional processing

• Error handling

• ServiceNow API invocation

• Oracle Fusion REST API invocation

• Logging and monitoring

• Enterprise-level integration governance

Prerequisites

Before implementing the integration, confirm the following.

Zabbix prerequisites

You should have:

• Supported Zabbix version

• Administrative access

• Hosts configured

• Triggers configured

• Actions configured

• ServiceNow media type/webhook

• Appropriate Zabbix user

• Access to the monitored hosts

For the current Zabbix ServiceNow webhook documentation, Zabbix 7.4 is documented as the current setup example.

ServiceNow prerequisites

For the webhook approach, create a dedicated integration user.

Zabbix documents the following roles for the ServiceNow service user:

• rest_api_explorer

• sn_incident_write

For Event Management connector implementation, ServiceNow documents the evt_mgmt_admin role as a prerequisite and requires suitable credentials for accessing the Zabbix server.

Network prerequisites

Verify:

Zabbix → ServiceNow connectivity

or, for Event Management:

ServiceNow → MID Server → Zabbix

Firewall rules, DNS resolution, TLS certificates, proxy settings, and outbound connectivity should be validated before application configuration begins.

Step-by-Step Build Process – Zabbix Webhook

Step 1 – Create the ServiceNow Integration User

In ServiceNow, create a dedicated technical user.

Avoid using an individual administrator account.

Example:

User ID: zabbix.integration
Active: Yes

Assign only the permissions required by the integration.

For the documented Zabbix webhook setup, the service user requires the roles:

rest_api_explorer
sn_incident_write

Step 2 – Identify the ServiceNow Instance URL

Example:

https://companydev.service-now.com/

Keep the URL available for the Zabbix media type configuration.

Do not hard-code environment-specific values into multiple actions.

For example:

DEV  → companydev.service-now.com
TEST → companytest.service-now.com
PROD → company.service-now.com

This makes migration much easier.

Step 3 – Configure the Zabbix Media Type

In Zabbix navigate to:

Administration → Media types

Import the ServiceNow webhook definition.

Zabbix documents importing the media_servicenow.yaml definition and then replacing the placeholders with the ServiceNow URL, username, password, and other configuration values.

Typical parameters include:

servicenow_url
servicenow_user
servicenow_password
tls_verify
urgency_for_average
urgency_for_high
urgency_for_disaster

Step 4 – Configure the Zabbix URL Macro

A useful implementation practice is to define:

{$ZABBIX.URL}

For example:

https://zabbix.company.com

Zabbix documents this global macro as a way to populate ServiceNow fields with links to Zabbix event information or graphs.

This gives the ServiceNow support engineer a direct path back to the monitoring source.

Step 5 – Create the Zabbix User Media

Create or update the Zabbix user responsible for notifications.

Add the ServiceNow media type.

Even though the webhook does not necessarily use the traditional “Send to” value in the same way as an email media type, Zabbix’s documented configuration requires the field to contain a value rather than being left empty.

Make sure the Zabbix user can access the hosts for which notifications should be generated.

Step 6 – Configure the Zabbix Action

Create an action based on your operational requirements.

Example:

Event source = Trigger
Severity >= High
Host Group = Production

Then configure the operation to send the event using the ServiceNow media type.

Do not simply send every Zabbix event to ServiceNow.

That creates unnecessary incidents and can quickly overwhelm support teams.

Step-by-Step Build Process – ServiceNow Zabbix Connector

When Event Management is the desired architecture, configure the connector from ServiceNow.

Step 1 – Create Zabbix Credentials

Create credentials containing the Zabbix server account information required by the connector.

ServiceNow documentation specifies that the Zabbix connector requires credentials capable of accessing the Zabbix server.

Step 2 – Navigate to Connector Instances

Navigate to:

All → Event Management → Integrations → Connector Instances

Select:

New

ServiceNow documents this navigation for creating the Zabbix server connector instance.

Step 3 – Configure Connector Fields

Typical configuration includes:

The schedule controls how frequently the connector checks for new information.

Step 4 – Configure MID Server

If a MID Server is required by your network architecture, select an available and valid MID Server.

The MID Server provides the controlled communication path between ServiceNow and systems inside the enterprise network.

This is particularly important when the Zabbix server is not directly reachable from the ServiceNow environment.

Step 5 – Test the Connector

Use:

Test Connector

Check:

• Connection status

• Authentication

• Network connectivity

• Zabbix response

• MID Server status

• Connector logs

After successful validation, activate the connector.

Testing the Integration

A proper test should cover more than successful incident creation.

Test Case 1 – Problem Event

Create a controlled Zabbix trigger condition.

Example:

CPU > 90%
Duration > 5 minutes

Expected result:

Zabbix Problem
       ↓
ServiceNow Event/Incident

Validate:

• Short description

• Severity

• Urgency

• Host

• CI

• Event ID

• Description

• Timestamp

• Zabbix URL

Test Case 2 – Recovery

Return the monitored system to normal.

Expected result:

Zabbix Recovery
       ↓
Existing ServiceNow event/incident updated

The objective is to confirm correlation rather than creating another incident.

Test Case 3 – Update

Add an update to the Zabbix problem.

Validate whether the ServiceNow record receives the expected update.

Test Case 4 – Duplicate Prevention

Generate repeated monitoring notifications.

The integration should not create dozens of incidents for the same underlying condition.

This test is particularly important in production implementations.

Common Errors and Troubleshooting

1. Authentication Failure

Symptoms:

401 Unauthorized
403 Forbidden

Check:

• Username

• Password

• User active status

• Required roles

• API access

• Authentication policy

For webhook implementations, verify the roles documented by Zabbix.

2. ServiceNow Incident Is Created Without the Correct CI

This is often not an API problem.

The API call may succeed while CI association fails.

Check:

Zabbix Host
      ↓
Hostname
      ↓
ServiceNow CI

Use a consistent naming convention.

For example:

Zabbix: PROD-APP-001
ServiceNow CI: PROD-APP-001

If names differ, introduce an explicit mapping strategy rather than depending on string matching.

3. Events Are Not Being Retrieved

For the ServiceNow connector architecture, check:

• MID Server status

• Zabbix server IP

• Credential

• Connector definition

• Schedule

• Firewall

• Zabbix API access

ServiceNow specifically documents the connector instance fields and MID Server configuration for Zabbix event collection.

4. Metrics Are Not Appearing

ServiceNow’s Zabbix metrics connector has additional requirements.

The MID Server retrieving metrics needs the Metric Intelligence extension configured and running. ServiceNow also notes that Zabbix discovery isn’t supported for this connector, so CI records must be created manually using the Zabbix hostname.

This is an important distinction between event ingestion and metric ingestion.

5. Too Many ServiceNow Incidents

This is usually a monitoring design problem rather than an integration defect.

Suppose Zabbix generates:

CPU warning
CPU high
CPU critical
CPU recovery

for the same server.

If each notification becomes an independent incident, the Service Desk receives unnecessary tickets.

Use:

• Severity thresholds

• Trigger dependencies

• Event correlation

• ServiceNow alert processing

• Incident creation rules

• Recovery correlation

Using Oracle Integration 3 in an Extended Architecture

When Oracle Fusion Cloud applications are part of the overall landscape, Oracle Integration 3 can provide a controlled integration layer.

For example:

Zabbix
   |
   v
ServiceNow
   |
   v
Oracle Integration 3
   |
   +--> Oracle Fusion ERP
   |
   +--> Oracle Fusion HCM
   |
   +--> Oracle Fusion SCM
   |
   +--> OCI REST API

The Oracle Integration 3 ServiceNow Adapter supports trigger and invoke patterns, REST and SOAP APIs, CRUD operations, queries, attachments, and OAuth-based authentication options.

A practical example could be:

ServiceNow Incident
       |
       | Priority = Critical
       v
OIC
       |
       | Validate CI
       | Transform payload
       | Apply routing
       v
Oracle Fusion REST API

The important design principle is not to insert OIC merely because another integration tool exists.

If:

Zabbix → ServiceNow

already satisfies the requirement, a direct integration may be simpler.

Use OIC when there is genuine enterprise orchestration, transformation, routing, security, or cross-application processing to justify the additional layer.

Best Practices for Zabbix ServiceNow Integration

1. Use a Dedicated Integration Account

Never build production integrations around a personal administrator account.

Use:

zabbix.integration

or an equivalent technical account.

2. Separate Environments

Maintain separate configurations for:

DEV
TEST
PROD

Never allow a test Zabbix server to accidentally create production incidents.

3. Design CI Mapping Early

Do not leave Configuration Item mapping until the end of the implementation.

Define the relationship between:

Zabbix Host
ServiceNow CI
Business Service
Assignment Group

before production testing.

4. Control Event Volume

A monitoring platform can generate thousands of events.

ServiceNow should receive operationally meaningful information, not every raw monitoring signal.

5. Protect Credentials

Do not store credentials in scripts, configuration files, or source repositories.

Use the appropriate credential mechanism for the selected integration architecture.

6. Preserve Correlation IDs

Always retain identifiers that allow the support team to trace:

ServiceNow Incident
       ↕
ServiceNow Alert
       ↕
Zabbix Event
       ↕
Zabbix Trigger

This makes troubleshooting significantly easier.

7. Test Recovery

Many implementations test only:

Problem → Incident

and forget:

Recovery → Update/Close

Recovery testing should be mandatory.

8. Disable Debug Logging After Testing

ServiceNow’s Zabbix connector documentation notes that the connector can log event and metric payloads for debugging and recommends disabling the debug payload logging after troubleshooting to avoid unnecessary logging volume.

Practical Implementation Checklist

Before moving the integration to production, validate the following:

• Zabbix version confirmed

• ServiceNow version/release confirmed

• Integration architecture selected

• Dedicated ServiceNow user created

• Required roles assigned

• Zabbix media type configured

• ServiceNow URL validated

• TLS verification configured

• Zabbix URL macro configured

• Zabbix actions configured

• MID Server validated if required

• CI mapping completed

• Severity mapping tested

• Problem event tested

• Recovery event tested

• Update event tested

• Duplicate prevention tested

• Invalid credentials tested

• Network failure tested

• Logging reviewed

• Production credentials secured

Frequently Asked Questions

1. Can Zabbix create ServiceNow incidents directly?

Yes. Zabbix provides a ServiceNow webhook integration that can create ServiceNow incidents from Zabbix events. The current documentation includes configuration for ServiceNow credentials, severity-to-urgency mapping, recovery and update handling for trigger-based events, and custom fields.

2. Do I need a MID Server for Zabbix ServiceNow integration?

It depends on the integration architecture. The ServiceNow Zabbix Event Management connector uses a connector instance and supports assigning a MID Server, while a direct Zabbix webhook sends requests toward the ServiceNow API.

3. Can Oracle Integration 3 be used between Zabbix and ServiceNow?

Yes, but it should be introduced when there is a real requirement for enterprise mediation, transformation, routing, security, or integration with other applications. Oracle Integration 3 provides a ServiceNow Adapter supporting trigger and invoke patterns and REST/SOAP-based ServiceNow integration.

Summary

Zabbix ServiceNow integration is more than simply creating a ServiceNow ticket whenever a monitoring alert occurs. A production-quality implementation needs decisions around event ingestion, incident creation, CI mapping, severity translation, event correlation, recovery processing, authentication, network connectivity, and operational ownership.

For a straightforward requirement, the Zabbix ServiceNow webhook provides a direct path from monitoring events to ServiceNow incidents. For organizations implementing ServiceNow Event Management, the Zabbix connector provides a different architecture based around event collection and MID Server connectivity.

Where Oracle Fusion Cloud or other enterprise applications must participate in the workflow, Oracle Integration 3 can act as the orchestration layer. Its ServiceNow Adapter supports bidirectional integration patterns and a range of REST/SOAP operations.

The most important implementation lesson is to design event lifecycle management, rather than only event creation:

Monitor
   ↓
Detect
   ↓
Filter
   ↓
Correlate
   ↓
Create Event/Incident
   ↓
Assign
   ↓
Resolve
   ↓
Recover
   ↓
Close

For additional Oracle Cloud reference material, use the Oracle Cloud Applications documentation and review the current 26A readiness documentation when an Oracle Fusion application participates in the architecture. Oracle’s 26A documentation provides release-specific information for Fusion Cloud applications. For the requested Time and Labor reference, see the Oracle Fusion Cloud Human Resources – Implementing Time and Labor guide, which documents Time and Labor setup and implementation tasks.