ServiceNow integration for incidents and CMDB
Connect Obseria to ServiceNow with Automation workflows and the ServiceNow REST API: problems become incidents with root-cause context, CIs are enriched from the CMDB and status stays in sync.
Why monitor ServiceNow with Obseria
Incidents with context
Each incident carries the affected service, impact, probable root cause and a link back to the evidence in Obseria.
Less noise in the queue
Only correlated problems create tickets, not every single alert, so assignment groups see one incident per issue.
Status in both directions
Updates and resolutions in ServiceNow flow back to Obseria, and Obseria updates the ticket when a problem recovers.
What the ServiceNow integration covers
- Incident creation. Obseria Automation workflows create incidents through the ServiceNow Table API when a problem opens.
- Incident updates and resolution. Work notes, severity changes and recovery are written to the same incident via its correlation ID.
- Bidirectional status. A ServiceNow business rule or flow calls the Obseria API so acknowledgements and closures appear in Obseria.
- CMDB enrichment. Configuration items from the CMDB are looked up so incidents reference the right CI, owner and assignment group.
- Change correlation. Change requests from ServiceNow can be sent to Obseria as deployment events next to the telemetry.
- Routing and priority. Impact and urgency are derived from service criticality and SLO burn, so priority follows business impact.
What gets synchronized
Obseria collects these values automatically and shows them in ready-made dashboards and alerts.Incident creation
Turns detected problems into clear tickets with a short summary and full explanation, without manual copying.
Priority and ownership
Sets business impact and urgency and routes each incident to the right team, so nothing sits unassigned.
Context and linking
Connects each incident to the affected system and to related alerts, so duplicates are avoided and root causes are clear.
Status updates
Keeps tickets current with progress notes and closes them automatically once the problem has been resolved.
Show all 9 metrics in detail
| Field | Type | Content |
|---|---|---|
short_description | field | Incident title built from the Obseria problem summary and affected service. |
description | field | Root-cause summary, chain of evidence and affected entities from Obseria Intelligence. |
impact | field | Set from the number of affected users or services and service criticality. |
urgency | field | Set from SLO burn rate or problem severity. |
assignment_group | field | Owning team, resolved from the service catalog or the CMDB CI. |
cmdb_ci | field | Reference to the configuration item that matches the affected Obseria entity. |
correlation_id | field | Obseria problem ID, used to update and close the same incident. |
work_notes | field | Timeline updates written by Obseria while the problem evolves. |
state | field | Incident state; changes are synchronized back to Obseria. |
Set up ServiceNow monitoring in minutes
- Step 1
Create an integration user
Create a ServiceNow user with only the roles needed for the incident and CMDB tables, and store its credentials as an Obseria secret.
- Step 2
Build the Automation workflow
Trigger an Obseria Automation workflow on problem open, update and close that calls the ServiceNow Table API.
- Step 3
Enable the return path
Add a ServiceNow business rule or flow that sends state changes to the Obseria API for bidirectional sync.
# Request an Obseria Automation workflow sends when a problem opens
# (ServiceNow Table API, incident table)
curl -s -X POST \
"https://${SN_INSTANCE}.service-now.com/api/now/table/incident" \
-u "${SN_USER}:${SN_PASSWORD}" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-d '{
"short_description": "checkout-api: error rate above SLO",
"description": "Probable root cause: connection pool exhaustion on orders-db",
"impact": "2",
"urgency": "1",
"cmdb_ci": "checkout-api",
"assignment_group": "Checkout Team",
"correlation_id": "obseria-problem-4711"
}'Out of the box
Dashboards, alerts and SLOs that are ready the moment data arrives.
- Open incidents by service and priority
- Problems without linked incident
- Time from detection to incident creation
- Incidents per CMDB CI
- Sync failures between Obseria and ServiceNow
ServiceNow monitoring: what matters
Why integrate observability with ServiceNow
In many organizations, ServiceNow is the system of record for incidents, changes and configuration items. Observability platforms, on the other hand, are where problems are detected and diagnosed. When the two are disconnected, engineers copy alert details into tickets by hand, incidents lack technical context, and the ticket status says little about whether the system has actually recovered. A ServiceNow integration closes that gap: detected problems become incidents automatically, with the information responders need, and both tools stay aligned until resolution.
The aim is not to create a ticket for every alert. A good ServiceNow incident integration creates one incident per real problem, routes it to the right team and keeps updating it as the situation develops. That reduces noise in the service desk and shortens the time to resolution.
How the data flows
From Obseria to ServiceNow
Obseria groups related alerts into a problem and determines the probable root cause. An Obseria Automation workflow, written as code, reacts to problem events and calls the ServiceNow Table API. On open, it creates an incident with short description, description, impact, urgency, assignment group and configuration item. The Obseria problem ID is stored in correlation_id, so later updates and the final resolution target the same record.
From ServiceNow to Obseria
For bidirectional status, a ServiceNow business rule or flow sends incident state changes, assignments and resolution notes to the Obseria API. Responders working in Obseria see whether the incident has been acknowledged and who owns it, without switching tools.
CMDB enrichment
A ServiceNow CMDB integration maps Obseria entities, such as services, hosts or databases, to configuration items. The workflow looks up the CI by name or another identifier and uses the CMDB to fill the owner and assignment group. TopoGraph adds the live dependencies that the CMDB may not know, so responders see both the registered CI and its current runtime context.
Common pitfalls and how to avoid them
- Ticket floods: creating incidents from raw alerts overwhelms the service desk. Trigger on correlated problems instead.
- Duplicate incidents: without a stable correlation ID, retries or flapping problems create new tickets. Always update by
correlation_id. - Stale tickets: incidents that stay open after recovery hide real issues. Let Obseria write recovery notes and propose resolution.
- Wrong routing: outdated CMDB data sends incidents to the wrong team. Compare CMDB relationships with the topology Obseria discovers and flag mismatches.
- Over-privileged accounts: the integration user should only access the tables it needs.
Change correlation
Many incidents follow a change. When ServiceNow change requests reach Obseria as deployment events, Obseria Intelligence can weigh them as candidate causes, and the incident description can name the related change number directly. That saves responders a manual search through the change calendar.
Best practices for ITSM integration
- Agree on a mapping from problem severity and SLO burn to ServiceNow impact and urgency before going live.
- Include a short root-cause summary and the affected services in the description, not raw metric dumps.
- Send ServiceNow change requests to Obseria as deployment events, so changes appear next to the telemetry they affect.
- Monitor the integration itself: failed API calls and sync delays should alert someone.
- Review closed incidents regularly to tune which problems should open a ticket.
How Obseria helps
Obseria Automation runs workflows as code, so the ServiceNow integration is versioned, reviewable and testable like any other code. Obseria Intelligence provides the root cause and chain of evidence that end up in the incident description, and the service catalog supplies ownership. Because API access, automation and alerting are included in every Obseria plan, connecting ServiceNow does not require an additional module. The result is fewer, better incidents and a shorter path from detection to resolution, which directly improves MTTR.
Related integrations
Related capabilities
Incident Management
Declare, route, coordinate and review incidents in the same platform that detected them, with on-call schedules, escalation, a live timeline and post-mortems built in.
Learn moreService Catalog
Every service, its owner, its dependencies and its SLOs in one place, discovered automatically from traces and topology and enriched with the metadata your teams provide.
Learn moreDeployment Tracking
Record every deployment and configuration change, see release markers on every chart and let Obseria compare before and after so you know within minutes whether a release improved or broke things.
Learn moreLearn more
What is MTTR (mean time to recovery)?
What is MTTR? Learn the four meanings of MTTR, how to calculate MTTR, MTTD, MTTA and MTBF with examples, and proven ways to reduce recovery time.
What is AIOps?
What is AIOps? Learn how AI for IT operations detects anomalies, correlates alerts, finds root causes and automates remediation, plus pitfalls to avoid.
ServiceNow monitoring FAQ
Through Obseria Automation workflows that call the ServiceNow REST API, mainly the Table API for the incident and CMDB tables. The return path uses a ServiceNow business rule or flow that calls the Obseria API.
No. You decide the trigger. The recommended setup creates incidents only for correlated problems, so one issue results in one incident.
Yes, when you configure the return path. Obseria updates the incident through its correlation ID, and ServiceNow sends state changes back to the Obseria API.
Yes. The workflow looks up the matching configuration item and sets cmdb_ci and the assignment group, so incidents land with the right team.
A dedicated integration user with read and write access to the incident table and read access to the CMDB tables you use. Avoid admin roles.
Start monitoring ServiceNow today
Connect ServiceNow in minutes with OpenTelemetry or the Obseria Agent. Free for 14 days.