Introduction

Grafana ServiceNow integration connects observability and IT service management so that monitoring events can move from Grafana into ServiceNow Event Management and become actionable operational records. In a typical enterprise environment, Grafana monitors applications, infrastructure, databases, Kubernetes workloads, APIs, and cloud resources, while ServiceNow provides the operational workflow for events, alerts, incidents, configuration items, assignment groups, and remediation.

The important point for an implementation consultant is that this integration is not simply about sending an alert from one product to another. A successful implementation must define authentication, event payload mapping, severity, node/resource identification, alert correlation, deduplication, assignment, and lifecycle management.

ServiceNow currently documents Grafana as an authenticated Event Management data source and provides Basic Authentication, OAuth, and REST API key authentication options.

This article walks through a practical implementation approach using current Grafana alerting concepts and ServiceNow Event Management.

What Is Grafana ServiceNow Integration?

Grafana ServiceNow integration allows Grafana-generated monitoring events to be sent to ServiceNow so that the operations team can process them through established IT service management workflows.

A simplified architecture looks like this:

Application / Infrastructure → Metrics → Grafana → Alert Rule → Contact Point → ServiceNow Event Management → Event Processing → Alert → CI / Incident Workflow

For example, suppose an Oracle database supporting an enterprise application begins experiencing high CPU utilization.

Grafana detects:

• CPU utilization above 90%

• Sustained for 10 minutes

• Environment = Production

• Application = Order Management

• Server = ord-db-prod-01

Grafana generates an alert and sends it to ServiceNow.

ServiceNow can then process the event, associate it with the appropriate configuration item, apply event rules, determine severity, and initiate the appropriate operational workflow.

This separation of responsibilities is useful:

ServiceNow’s current Grafana integration documentation specifically describes adding Grafana as an authenticated data source for Event Management.

Why Integrate Grafana with ServiceNow?

A monitoring dashboard alone does not provide an operational process.

Consider a production environment where 500 servers are monitored by Grafana. A dashboard may show that several servers are experiencing problems, but the support organization may still need:

1. Event classification

2. Severity determination

3. CI identification

4. Assignment to an operations group

5. Incident creation

6. Investigation

7. Resolution

8. Audit history

ServiceNow provides the workflow layer around the monitoring information.

The integration becomes particularly useful when organizations want to connect observability with ITSM processes rather than asking operations teams to manually create tickets from monitoring dashboards.

Key Capabilities

Grafana Alerting

Modern Grafana alerting allows alert rules to evaluate metrics and trigger notifications when conditions are satisfied.

A practical rule could be:

Metric: CPU utilization
Condition: > 90%
Duration: 10 minutes
Environment: Production
Severity: Critical

The alert should contain enough contextual information for ServiceNow to process it correctly.

ServiceNow Event Management

ServiceNow receives the event and processes the information according to configured Event Management rules.

The current ServiceNow documentation states that Grafana events can be integrated using Basic Authentication, OAuth authentication, or REST API key authentication.

CI Identification

One of the most important implementation areas is identifying the affected configuration item.

For example:

node = ord-db-prod-01
resource = oracle-database
metric_name = cpu_utilization

If the node information can be mapped reliably to a CI in the CMDB, the operations team gets considerably more useful context than simply receiving a generic “CPU high” event.

Severity Mapping

Grafana can pass severity through alert labels. ServiceNow’s documented Grafana integration supports severity values such as:

• Critical

• Major

• Minor

• Warning

ServiceNow’s documentation also notes that severity can be passed through custom labels and used for events.

Real-World Grafana ServiceNow Use Cases

Use Case 1 – Production Application Server Monitoring

An organization operates an e-commerce application across multiple production servers.

Grafana monitors:

• CPU

• Memory

• Disk utilization

• Network latency

• HTTP response time

• Application availability

Suppose the application server app-prod-03 reaches 95% CPU for more than 10 minutes.

Grafana raises a critical alert and sends:

node = app-prod-03
resource = application-server
metric_name = cpu_usage
severity = critical
environment = production

ServiceNow receives the event, identifies the server CI and applies the appropriate event processing rules.

This gives the operations team a traceable operational event instead of relying on someone watching a Grafana dashboard.

Use Case 2 – Kubernetes Platform Monitoring

A Kubernetes platform may contain hundreds of pods and nodes.

Grafana can monitor:

• Node CPU

• Node memory

• Pod restart count

• Container memory

• API latency

• Cluster availability

A rule such as:

Pod restart count > 20 within 10 minutes

can generate an event.

The event can include:

cluster = production-cluster
namespace = payments
pod = payment-api-7d8f9
severity = major

ServiceNow can then route the event to the Kubernetes or platform operations team.

The important implementation decision is to avoid generating an individual incident for every pod restart. Event correlation and grouping should be designed before production deployment.

Use Case 3 – Database Performance Monitoring

Consider an Oracle database supporting an ERP application.

Grafana monitors:

• Database CPU

• Connection count

• Query latency

• Tablespace utilization

• Database availability

Suppose database connection utilization exceeds the defined threshold.

Grafana sends an event containing:

node = erp-db-prod-01
resource = oracle-database
metric_name = connection_utilization
severity = major
application = ERP
environment = production

ServiceNow can associate the event with the database CI and route it to the database support group.

This is much more useful than sending an alert with only the text:

Database connections are high.

Architecture and Technical Flow

A practical architecture can be represented as follows:

+----------------------+
| Application / Server |
+----------+-----------+
           |
           v
+----------------------+
| Metrics / Telemetry  |
+----------+-----------+
           |
           v
+----------------------+
|       Grafana        |
| Dashboards + Alerts  |
+----------+-----------+
           |
           | HTTPS
           v
+----------------------+
| ServiceNow Event     |
| Management Endpoint  |
+----------+-----------+
           |
           v
+----------------------+
| Event Processing     |
| Rules / Correlation  |
+----------+-----------+
           |
           v
+----------------------+
| CI / Alert / Incident|
+----------------------+

There are effectively two important integration directions.

Grafana → ServiceNow

This is the common monitoring flow:

Grafana Alert
      ↓
Contact Point
      ↓
Webhook
      ↓
ServiceNow Event Management
      ↓
Event Processing
      ↓
Alert / Incident Workflow

ServiceNow → Grafana

A reverse flow can also be useful in more advanced implementations.

For example, Grafana can query ServiceNow data to visualize:

• Open incidents

• Critical incidents

• Incident trends

• Change activity

• Incident volume by category

Grafana’s ServiceNow data source can query and visualize ServiceNow table data and supports metrics, alerting and annotations.

This means the integration does not have to be limited to pushing alerts into ServiceNow.

Prerequisites

Before starting the implementation, confirm the following.

Grafana prerequisites

You should have:

• Grafana environment

• Administrator access for data source or alert configuration

• Alert rules

• Contact point configuration

• Notification policy

• HTTPS connectivity to ServiceNow

For Grafana’s ServiceNow data source specifically, current documentation lists Grafana 11.6.7 or later and a ServiceNow account with access to the required tables. The Enterprise plugin is available with Grafana Cloud Pro/Advanced and Grafana Enterprise.

ServiceNow prerequisites

The ServiceNow side should have:

• Event Management capability

• Grafana integration configured

• Integration user

• Required authentication method

• Appropriate roles and permissions

• Event processing rules

• CMDB records for important monitored infrastructure

• Network connectivity from Grafana

For Basic Authentication, ServiceNow documentation specifies using a user with the evt_mgmt_integration role and recommends using the least-privileged appropriate user rather than a highly privileged account.

Step-by-Step Build Process

Step 1 – Decide the Event Contract

Before configuring Grafana, define what information ServiceNow needs.

A practical event contract might look like:

Do this before creating alert rules.

A common project mistake is configuring alerts first and deciding later what ServiceNow should receive.

Step 2 – Configure the ServiceNow Integration

ServiceNow currently provides a dedicated Grafana Event Management integration.

Navigate within ServiceNow according to your Event Management implementation and configure Grafana as an authenticated data source.

The supported authentication options documented by ServiceNow are:

1. Basic Authentication

2. OAuth

3. REST API key authentication

For production environments, select the method according to your organization’s security architecture rather than simply choosing the easiest configuration.

Step 3 – Create the Integration User

For a Basic Authentication implementation, create or designate a dedicated integration user.

Example:

User ID: grafana_evt
Purpose: Grafana → ServiceNow Event Management
Role: evt_mgmt_integration

Avoid using:

admin

or another broad administrative account.

The ServiceNow documentation specifically recommends the least-privileged user with the required integration role.

Step 4 – Configure the Grafana Contact Point

In Grafana, navigate to:

Alerting → Contact Points

Create a new contact point and select:

Webhook

For the documented ServiceNow Event Management endpoint pattern, the URL is similar to:

https://<instance-name>.service-now.com/api/sn_em_connector/em/inbound_event?source=grafana

Use your actual ServiceNow instance name.

ServiceNow’s current documentation describes this endpoint pattern for the Grafana integration.

Set:

HTTP Method = POST

Configure the authentication information required by your selected authentication method.

Then use:

Save and Test

The objective at this stage is only to prove connectivity and authentication.

Step 5 – Configure Notification Policies

Navigate to:

Alerting → Notification Policies

Create a policy that determines which alerts should be sent to the ServiceNow contact point.

For example:

environment = production
severity = critical

can be routed to the ServiceNow integration.

Do not automatically send every informational alert to ServiceNow.

Otherwise, a high-volume monitoring environment can quickly generate operational noise.

ServiceNow’s documented Grafana procedure uses notification policies and matchers to direct alert rules to the appropriate contact point.

Step 6 – Create the Grafana Alert Rule

Navigate to:

Alerting → Alert Rules → New Rule

Configure:

• Query

• Alert condition

• Evaluation interval

• Pending duration

• Rule name

• Summary

• Description

• Custom labels

Example:

Rule:
Production Database CPU

Condition:
CPU > 90%

For:
10 minutes

Labels:
severity = critical
environment = production
application = ERP

The ServiceNow integration documentation recommends providing node, resource and metric information because these fields are required for the corresponding event data.

Step 7 – Pass Node and Resource Information

This is one of the most important technical steps.

For example, the node can be populated dynamically from an alert value or label:

node = {{ $values.C0.Labels.instance }}

The exact expression depends on your query and alert structure.

ServiceNow’s documentation specifically describes passing node information using Grafana value strings and states that node, resource and metric information are required for those event fields.

Step 8 – Add Custom Labels

Use custom labels to control routing and classification.

Example:

severity = critical
environment = production
application = order-management
support_group = middleware

Keep labels standardized across alert rules.

A consultant should avoid creating:

sev = critical
severity = critical
priority = P1
criticality = high

for the same business meaning.

Choose one standard and document it.

Testing the Integration

Do not start by testing against a real production incident.

Use a non-production environment first.

Test Case 1 – Connectivity

Use Grafana:

Alerting → Contact Points → ServiceNow Contact Point → Test

Expected result:

• Request reaches ServiceNow

• Authentication succeeds

• No HTTP authentication error

• ServiceNow accepts the event

Test Case 2 – Generate a Controlled Alert

Create a temporary rule such as:

Test metric > 80

Generate the condition deliberately.

Expected result:

Grafana alert = Firing
        ↓
Contact point triggered
        ↓
ServiceNow receives event
        ↓
Event appears in ServiceNow

ServiceNow’s documented result is that alerts flow into Event Management, where the integration extracts information from the Grafana alert message and inserts the event into the database.

Test Case 3 – Validate Severity

Send:

severity = critical

Verify that ServiceNow receives the expected severity.

Then repeat with:

severity = warning

This validates label mapping.

Test Case 4 – Validate CI Identification

Use a known server:

app-test-01

Verify that ServiceNow associates the event with the correct CI.

If CI identification fails, investigate:

• Host naming

• CI naming conventions

• Discovery data

• Matching rules

• Event field mapping

Test Case 5 – Validate Recovery

Trigger the alert and then return the metric to normal.

Verify that the event lifecycle behaves as expected.

This test is important because an integration that only creates events but never handles recovery can create unnecessary operational workload.

Common Errors and Troubleshooting

401 Unauthorized

Possible causes:

• Incorrect credentials

• Wrong authentication method

• Integration user missing the required role

• Expired credential

For Basic Authentication, verify the evt_mgmt_integration role and account configuration.

403 Forbidden

The credentials may be valid, but the user may not have sufficient permissions.

Check the ServiceNow user’s roles and ACLs.

Avoid solving the issue by assigning broad administrator privileges.

404 Not Found

Check:

• ServiceNow instance URL

• Endpoint path

• Event Management installation

• Environment

• URL parameters

For example, compare the configured endpoint against the documented pattern:

/api/sn_em_connector/em/inbound_event?source=grafana

Events Arrive but CI Is Not Identified

This is usually a data-quality or mapping issue rather than a connectivity issue.

Check:

Grafana node
      ↓
ServiceNow event node
      ↓
CI identification
      ↓
CMDB record

If the names do not align, ServiceNow may receive the event successfully but fail to associate it with the expected CI.

Too Many Incidents

This is a classic production implementation problem.

Suppose one application generates:

CPU high
Memory high
Disk high
Latency high
Pod restart
Connection high

within two minutes.

Creating six separate incidents may overwhelm the support team.

Review:

• Alert thresholds

• Notification policies

• Event correlation

• Deduplication

• Grouping

• CI relationships

The goal should be actionable operational events, not maximum alert volume.

Grafana Test Works but Production Alerts Do Not

Check whether the production alert actually matches the notification policy.

For example:

Notification policy:
environment = production

but the alert label says:

env = prod

The values are logically similar but technically different.

Standardize labels before deployment.

Best Practices

1. Use a Dedicated Integration Account

Create an account specifically for Grafana integration.

Do not reuse human administrator credentials.

2. Use Least Privilege

Grant only the roles and permissions necessary for the integration.

ServiceNow explicitly recommends using the least-privileged appropriate user for the Grafana Event Management integration.

3. Standardize Alert Labels

Define a project-wide label model.

For example:

application
environment
severity
service
team
node
resource

This makes notification policies and event processing easier to maintain.

4. Design CMDB Mapping Early

Do not treat CMDB identification as a final step.

Before production deployment, confirm that monitored nodes can be mapped to ServiceNow CIs.

5. Avoid Alert Storms

Not every Grafana alert should become an incident.

Use appropriate thresholds, grouping and event processing.

6. Monitor API Usage

Integrations generate API traffic.

If Grafana queries ServiceNow frequently, keep queries focused and avoid unnecessary high-frequency polling.

Grafana’s ServiceNow data source documentation specifically recommends focused queries, appropriate evaluation intervals and awareness of ServiceNow API rate limits when using ServiceNow data for alerting.

7. Use Grafana for Visualization and ServiceNow for Operational Workflow

Do not try to duplicate the entire ServiceNow incident process inside Grafana.

Similarly, do not expect ServiceNow to replace detailed metric visualization.

A clean division of responsibilities produces a more maintainable architecture.

8. Consider Bidirectional Integration Carefully

Advanced environments may synchronize incident status between Grafana incident-management capabilities and ServiceNow.

Grafana documents bidirectional webhook patterns for external systems such as ServiceNow, including sending incident events externally and processing updates back into Grafana.

When implementing bidirectional synchronization, always define loop-prevention logic.

For example:

Grafana creates SN incident
        ↓
ServiceNow updates incident
        ↓
ServiceNow sends update to Grafana
        ↓
Grafana must NOT create another SN incident

Grafana’s published ServiceNow integration example explicitly uses filtering to avoid a synchronization loop when the ServiceNow-side incident originated from Grafana.

Frequently Asked Questions

What is Grafana ServiceNow integration?

It is an integration pattern that connects Grafana monitoring and alerting with ServiceNow Event Management. Grafana generates monitoring events, while ServiceNow processes those events through IT operations workflows.

Can Grafana send alerts directly to ServiceNow?

Yes. Grafana can send alerts using a webhook contact point, while ServiceNow provides an Event Management endpoint for Grafana events. The current ServiceNow documentation describes Basic Authentication, OAuth and REST API key authentication options.

Can Grafana display ServiceNow incidents?

Yes. Grafana’s ServiceNow data source allows ServiceNow table data to be queried and visualized. It can be used for dashboards, annotations and alerting based on ServiceNow data.

Expert Implementation Checklist

Before moving a Grafana-ServiceNow integration to production, validate:

• ServiceNow Event Management is available

• Grafana alerting is configured

• Dedicated integration account created

• Least-privilege permissions assigned

• Authentication method selected

• HTTPS connectivity verified

• Grafana contact point configured

• Notification policy configured

• Standard labels defined

• Node/resource/metric fields populated

• CMDB CI matching tested

• Severity mapping tested

• Recovery behavior tested

• Duplicate event behavior tested

• Alert storm scenario tested

• Production monitoring and logging established

Summary

Grafana ServiceNow integration is most effective when it is implemented as an observability-to-operations workflow, rather than as a simple webhook connection.

Grafana should identify meaningful technical conditions through metrics and alert rules. ServiceNow should then provide the operational processing layer through Event Management, CI identification, event rules, correlation and downstream incident workflows.

The most important implementation decisions are not the webhook URL or authentication credentials. They are the event contract, severity model, CI mapping, alert grouping, deduplication and lifecycle strategy.

For larger enterprise implementations, start with one controlled use case—such as production CPU monitoring—validate the complete lifecycle, and then expand to databases, Kubernetes, applications and cloud infrastructure.

For the latest ServiceNow-specific Grafana integration details, use the current ServiceNow documentation because authentication options, release behavior and Event Management capabilities can change between releases. ServiceNow’s current documentation includes the Grafana integration and authentication-specific procedures.

For Oracle Cloud-related integrations that coexist with ServiceNow and Grafana, refer to the current Oracle Fusion Cloud Applications documentation and, where Time and Labor is part of the solution, the Oracle Fusion Cloud Time and Labor 26A documentation. Students should refer to the relevant product-specific documentation before implementing integrations in a production environment.