How do we integrate Dynatrace with ServiceNow and PagerDuty for incident routing and automated ticket creation?
Application Observability

How do we integrate Dynatrace with ServiceNow and PagerDuty for incident routing and automated ticket creation?

10 min read

Dynatrace becomes most valuable when its answers don’t stop at an alert—they immediately shape how incidents are routed, prioritized, and resolved. Integrating Dynatrace with ServiceNow and PagerDuty is how you turn precise, causation-based problem detection into automated ticket creation, intelligent on-call routing, and closed-loop remediation.

This guide walks through how to integrate Dynatrace with ServiceNow and PagerDuty for incident routing and automated ticket creation, and how to design the flows so you prevent alert storms instead of amplifying them.


Why connect Dynatrace, ServiceNow, and PagerDuty?

In modern hybrid and multi-cloud environments, incidents rarely map 1:1 to a single metric. You need:

  • Root-cause–level alerts from Dynatrace, not raw symptoms
  • Structured incidents and changes in ServiceNow for governance and auditability
  • Real-time on-call routing and escalation in PagerDuty for fast response

When you integrate Dynatrace with both ServiceNow and PagerDuty:

  • Dynatrace detects, analyzes, and explains issues (using Davis® AI and real-time topology).
  • PagerDuty routes and escalates the incident to the right responder in real time.
  • ServiceNow records and orchestrates the incident, changes, and problem records.

The result: fewer tickets, fewer false positives, and a workflow that can progress from alert to auto-remediation without leaving gaps in governance.


Integration models at a glance

There are three dominant patterns for integrating Dynatrace with ServiceNow and PagerDuty:

  1. Dynatrace → ServiceNow (incidents) → PagerDuty (via ServiceNow)

    • ServiceNow is your “system of record.”
    • PagerDuty notifications are driven from ServiceNow incident state.
    • Good when ITIL processes are central and tightly controlled.
  2. Dynatrace → PagerDuty (alerts) + Dynatrace → ServiceNow (incidents)

    • Dynatrace emits to both systems directly.
    • PagerDuty handles real-time response; ServiceNow holds the full ITSM history.
    • Good when speed of response and clean audit trails are both critical.
  3. Dynatrace → PagerDuty (real-time) → ServiceNow (synchronization from PagerDuty)

    • PagerDuty is the front door for incident response.
    • ServiceNow syncs from PagerDuty for records and downstream processes.
    • Good when incident routing is already standardized around PagerDuty.

Dynatrace supports all three, using a combination of built-in integrations, alerting profiles, and Workflows.


Core building blocks in Dynatrace

Before wiring ServiceNow and PagerDuty, configure how Dynatrace will produce the signals:

  1. Problem detection and Davis® AI

    • Dynatrace Intelligence automatically baselines metrics, logs, traces, and UX data.
    • When anomalies occur, Davis® AI determines causation-based root cause instead of firing separate alerts on each symptom.
    • You’re notified on problems, not raw events—critical to avoid ticket floods.
  2. Alerting profiles and notification settings

    • Use alerting profiles to define who gets notified about which problems:
      • Scope by management zone, tags (e.g., team:payments), or technology.
      • Filter by severity (e.g., only availability and error problems).
    • Attach notification integrations (ServiceNow, PagerDuty, Webhook) to each profile.
  3. Workflows and automation

    • Use Dynatrace Workflows to:
      • Enrich problems with additional context.
      • Call external APIs (ServiceNow, PagerDuty) conditionally.
      • Trigger auto-remediation or custom code based on current or forecasted events.

These primitives ensure that when ServiceNow or PagerDuty receives a signal, it’s already curated to root cause and team ownership.


Integrating Dynatrace with ServiceNow

The goal of the Dynatrace–ServiceNow integration is to automatically create and update incidents (and optionally CMDB CIs, events, and problems) based on Dynatrace problems.

1. Decide your ServiceNow integration scope

First, clarify what you want generated in ServiceNow from Dynatrace:

  • Incidents only (most common):
    • Each Dynatrace problem → ServiceNow incident.
  • Incidents + Events:
    • Use ServiceNow Event Management to aggregate and correlate.
  • CMDB population:
    • Synchronize Dynatrace-discovered entities and topology to ServiceNow CIs.

For automated ticket creation and routing, start with incidents and add events/CMDB later if required.

2. Configure the ServiceNow integration in Dynatrace

  1. In Dynatrace, go to Settings → Integration and locate the ServiceNow integration.

  2. Provide ServiceNow instance details:

    • Instance URL (e.g., https://your-instance.service-now.com)
    • Integration user credentials or OAuth token with permissions to:
      • Create and update incident records
      • (Optionally) create events and maintain CMDB CIs
  3. Map fields:

    • Short description: Use problem title plus Davis® AI impact summary.
    • Description: Insert Dynatrace problem details, affected entities, and root cause explanation.
    • Assignment group: Derive via:
      • Static mapping (e.g., “Cloud Ops,” “Payments Team”)
      • Custom field mapping from Dynatrace tags or management zones
    • Priority / Severity:
      • Map Dynatrace problem severity to ServiceNow priority (e.g., availability = P1).
  4. Choose incident lifecycle behavior:

    • Auto-resolve incidents when Dynatrace closes the problem.
    • Update existing incidents instead of opening new ones if the problem key matches.

3. Control when incidents are created

Use alerting profiles to ensure only meaningful problems become tickets:

  • Create an alerting profile like “ServiceNow_INC_Prod”:
    • Scope: Production management zones.
    • Problem filters:
      • Severity: availability, error, slowdown.
      • Impact: Affects real users, business-critical services, or SLOs.
  • Attach the ServiceNow notification to this profile.

This keeps low-level issues (e.g., short-lived CPU spikes) out of ServiceNow while still visible in Dynatrace.

4. Route incidents correctly within ServiceNow

Once incidents reach ServiceNow, use standard ITSM routing mechanisms:

  • Assignment rules based on:
    • CI or application name (populated from Dynatrace topology).
    • Tags mapped from Dynatrace (e.g., team:payments → “Payments Ops” group).
  • Business rules to:
    • Set SLAs based on priority and impact.
    • Trigger workflows (e.g., change requests, problem records) for repeated incidents.
  • Incident state sync:
    • When Dynatrace declares the problem resolved, update the ServiceNow incident to “Resolved” and log the Davis® AI root cause summary in work notes.

This ensures full ITIL traceability while keeping incident data grounded in real runtime evidence from Dynatrace.


Integrating Dynatrace with PagerDuty

PagerDuty is built for real-time incident routing and escalation. The Dynatrace integration focuses on delivering precisely-scoped notifications to the right PagerDuty services.

1. Decide how many PagerDuty services you need

Align Dynatrace alert sources with PagerDuty services:

  • One service per critical application (e.g., “Checkout,” “Identity”).
  • One service per platform domain (e.g., “Kubernetes Platform,” “Database Ops”).
  • One service per business capability if you operate by value streams.

You’ll connect these services to specific alerting profiles and scopes in Dynatrace.

2. Configure the PagerDuty integration in Dynatrace

  1. Create or identify a PagerDuty service:

    • In PagerDuty, go to Services → Service Directory → New Service.
    • Choose integration type “Events API v2” (or Dynatrace-specific if available).
    • Copy the Integration Key.
  2. In Dynatrace, go to Settings → Integration → Problem notifications:

    • Add a PagerDuty notification.
    • Paste the PagerDuty Integration Key.
    • Configure message content:
      • Summary: Dynatrace problem title.
      • Details: Root cause, affected entities, impact, link back to Dynatrace problem.
    • Decide whether Dynatrace should send:
      • trigger on problem open.
      • resolve when the problem is fixed.
  3. Map multiple PagerDuty services:

    • Create separate notifications per service (e.g., “PagerDuty – Payments,” “PagerDuty – Platform”).
    • Attach each to the appropriate alerting profile.

3. Drive intelligent incident routing via alerting profiles

Use Dynatrace context to route alerts straight to the right on-call team:

  • Create alerting profiles such as:

    • “PagerDuty_Payments_Prod”:
      • Scope: tag team:payments, env:prod.
      • Notification: PagerDuty – Payments.
    • “PagerDuty_Platform_Prod”:
      • Scope: tag team:platform, env:prod.
      • Notification: PagerDuty – Platform.
  • Use problem filters to:

    • Exclude non-critical performance degradations if they shouldn’t wake people at night.
    • Include only problems impacting end users, SLOs, or critical dependencies.

PagerDuty then applies your escalation policies and schedules to notify responders, while Dynatrace ensures only meaningful, root-cause events are emitted.


Using Dynatrace Workflows for advanced routing and automation

For more complex scenarios—especially where you want conditional behavior or multi-step orchestration—Dynatrace Workflows are the right abstraction.

1. Trigger workflows from problems or forecasts

Workflows can be triggered when:

  • A new Dynatrace problem is opened or updated.
  • A specific metric or SLO breaches.
  • Dynatrace forecasting predicts a future threshold violation (e.g., disk filling up).

This allows you to prevent incidents rather than only reacting once they’re visible to users.

2. Branch logic to decide when to create tickets and alerts

Inside a workflow, you can:

  • Fetch problem details (root cause, impacted services, SLO status).
  • Make decisions based on:
    • Environment (env:prod vs env:dev).
    • Severity and impact.
    • Business criticality of the service.
  • Then:
    • Call ServiceNow API to create/update an incident with enriched context.
    • Call PagerDuty Events API to trigger or suppress alerts.
    • Trigger auto-remediation, and only if it fails, open incidents and page humans.

Example decision pattern:

  1. On problem open:
    • If impact = “critical business service” AND environment = “prod”
      • Trigger PagerDuty and create ServiceNow incident.
    • If impact = “non-critical” AND auto-remediation succeeded
      • Record in ServiceNow as a low-priority incident or log-only record.
      • Do not page on-call.

This keeps humans focused on issues that truly require intervention.


Coordinating ServiceNow and PagerDuty together

When both ServiceNow and PagerDuty are in play, design your flow so you don’t create duplicate or conflicting incidents.

Pattern A: Dynatrace → PagerDuty + ServiceNow in parallel

  1. Dynatrace problem detected.

  2. Dynatrace Workflows:

    • Triggers PagerDuty for immediate responder engagement.
    • Creates a ServiceNow incident with:
      • PagerDuty incident link.
      • Dynatrace problem link and Davis® AI root cause.
  3. State synchronization:

    • When Dynatrace resolves the problem:
      • Sends a resolve to PagerDuty.
      • Updates the ServiceNow incident with resolution summary and root-cause context.

Use this when your teams want real-time response via PagerDuty but process and audit anchored in ServiceNow.

Pattern B: Dynatrace → ServiceNow → PagerDuty

  1. Dynatrace creates a ServiceNow incident based on problem.
  2. ServiceNow business rules:
    • Automatically trigger PagerDuty via ServiceNow’s PagerDuty integration or outbound REST action.
  3. Resolving:
    • Either:
      • Dynatrace resolution → ServiceNow incident resolved → PagerDuty resolved.
      • Or PagerDuty acknowledgement/resolution updates ServiceNow, while Dynatrace closes the problem independently.

Use this when ServiceNow is the central orchestrator and you want all incidents to pass through its business logic before going to PagerDuty.


Best practices to avoid alert and ticket fatigue

Integrating three powerful systems can either simplify your world or multiply noise. A few design principles help ensure it’s the former:

  1. Only send root-cause alerts

    • Rely on Dynatrace’s causation-based Davis® AI to suppress symptomatic noise.
    • Avoid separate ServiceNow / PagerDuty signals for each affected node or metric.
  2. Align severity mapping

    • Ensure Dynatrace problem severity, ServiceNow priority, and PagerDuty urgency/escalation levels are consistent.
    • E.g., availability issues for revenue-critical services are always P1/High/Urgent.
  3. Scope by ownership

    • Use Dynatrace management zones and tags to map services to teams.
    • Attach ServiceNow and PagerDuty integrations to those scopes, not globally.
  4. Start narrow, then expand

    • Pilot with a single critical service path (e.g., checkout) and a subset of teams.
    • Adjust logic, severity thresholds, and workflows before rolling out globally.
  5. Use forecasts for preventive tickets

    • Configure Dynatrace forecasting (e.g., disk growth, memory pressure, SLO drift).
    • Trigger low-priority ServiceNow tasks or proactive PagerDuty notifications before user impact.
  6. Maintain governance and trust

    • Use ServiceNow records and Dynatrace problem history to document:
      • Why an automated action was taken.
      • Which Davis® AI causation chain justified it.
    • Leverage your security and data policies (Dynatrace Trust Center guidelines) to keep integrations compliant.

Example end-to-end flow

Putting it all together, a typical end-to-end flow might look like this:

  1. Dynatrace detects an availability issue in a Kubernetes-based payments service.
  2. Davis® AI analyzes topology and code-level traces, identifies the failing service and misconfigured deployment as root cause.
  3. A problem is opened and matched by an alerting profile:
    • Env: prod, Service: payments, Severity: availability.
  4. A Dynatrace Workflow runs:
    • Triggers PagerDuty – Payments with problem details.
    • Creates a ServiceNow incident, assigning to “Payments SRE” group and mapping to the correct CI.
    • Optionally executes a safe auto-remediation step (e.g., rollback via CI/CD API).
  5. The on-call engineer gets the PagerDuty alert with links to:
    • Dynatrace problem, root cause, and topology map.
    • ServiceNow incident for logging and ITIL processes.
  6. Once Dynatrace verifies that the service is healthy again:
    • The problem is resolved.
    • PagerDuty incident is auto-resolved.
    • ServiceNow incident is updated with a resolution note summarizing the Davis® AI root cause and any actions taken.

This is what preventive and autonomous operations look like in practice: Dynatrace provides the answers, ServiceNow and PagerDuty structure how humans and automation act on them.


Next step

If you want to see how Dynatrace can drive precise, low-noise incident routing into ServiceNow and PagerDuty in your own environment, the fastest path is a live, targeted demo.

Get Started