In many operations teams, an alert fires, someone on L1 reads it, and then copies the details into ServiceNow by hand. It's slow, it's error-prone, and at 3am it often doesn't happen at all. Here's how to automate it.
The basic pattern
- Alert fires in Azure Monitor, Sentinel or Datadog.
- An automation step receives the alert payload.
- It creates or updates an incident in ServiceNow through its REST API.
- When the alert resolves, the same step updates or closes the incident.
Azure Monitor
Attach an action group to your alert rules. The action group calls a webhook or, more flexibly, a Logic App. Enable the common alert schema so every alert arrives in the same shape, then map its fields (severity, resource, description) to ServiceNow incident fields.
Microsoft Sentinel
Use an automation rule that runs a playbook (a Logic App) when an incident is created. The playbook opens the ServiceNow incident and can write the ticket number back into the Sentinel incident as a comment, so analysts can jump between the two.
Datadog
Datadog has a ServiceNow integration. Once configured, monitors can create incidents by mentioning the ServiceNow handle in the notification message.
Things that make or break it
- De-duplication: use a correlation ID (for example the alert ID) so a flapping alert updates one ticket instead of creating fifty.
- Severity mapping: agree up front how alert severities map to ServiceNow impact and urgency.
- Assignment: route by resource tags (owner, application) so tickets land with the right team.
- Noise first: fix noisy alerts before you automate them, or you'll just automate the noise.
The goal isn't more tickets. It's every real problem getting a ticket within seconds, with enough context that the first engineer can act on it.
Need this set up?
Alert-to-ticket automation is one of my consulting services. I'll design the flow, build it, and hand it over with documentation.