Page Your On-Call Engineer with PagerDuty

Connect with PagerDuty

1. On the PagerDuty card, click "Connect with PagerDuty" and sign in to PagerDuty.
2. Approve access, then pick the service that should receive SutramX incidents.
3. SutramX adds a "SutramX" integration to that service for you. Nothing to copy.

Or paste an Events API v2 routing key

1. In PagerDuty, open Services → Service Directory and choose the service that should receive SutramX incidents (or create one).
2. Open the Integrations tab and click "Add an integration".
3. Choose Events API V2 and add it.
4. Expand the new integration and copy the Integration Key. This is the routing key SutramX needs.

How incidents flow

• Monitor goes down: a PagerDuty incident is triggered on that service.
• Monitor recovers: the PagerDuty incident is resolved automatically.
• Acknowledging the incident in SutramX also acknowledges it in PagerDuty.
• An escalation step that targets PagerDuty triggers again on the same PagerDuty incident instead of opening a new one.

Each SutramX incident maps to exactly one PagerDuty incident: SutramX uses its incident ID as PagerDuty's dedup_key, so repeated sends land on the same page. The sync is one-way. Acknowledging or resolving in PagerDuty does not change the incident in SutramX.

With one-click connect, EU-hosted PagerDuty accounts are detected automatically, and the connection is named after the service, for example "PagerDuty · Checkout". With a pasted key you can give it a name of up to 60 characters. The key is stored encrypted and only its last 4 characters are shown afterwards.

What PagerDuty receives

A trigger is an Events API v2 event with severity critical. The summary is the monitor name with "is DOWN", the source is the monitored URL, and custom_details carry the monitor name, URL, the confirming region and the failure reason:

{
  "event_action": "trigger",
  "dedup_key": "<SutramX incident id>",
  "payload": {
    "summary": "Checkout API is DOWN",
    "source": "https://api.example.com/health",
    "severity": "critical",
    "component": "sutramx-monitor",
    "custom_details": {
      "monitor_name": "Checkout API",
      "monitor_url": "https://api.example.com/health",
      "region": "FRA1 (Frankfurt, Germany)",
      "reason": "<failure reason>"
    }
  }
}

The recovery is a resolve event and the acknowledgement an acknowledge event, both with the same dedup_key. PagerDuty only ever receives real incidents: SSL and domain reminders, maintenance and other notices never page anyone.

Routing and escalation

You can connect up to 10 PagerDuty services, for example one per team. Open a connection's menu and choose Routing to send all monitors, selected groups or selected monitors to it. Recoveries ignore routing, so a page that was opened is always resolved, even if you changed the routing in between.

PagerDuty can also be a step in a SutramX escalation policy (on Growth and Pro). A common pattern: chat and email alert first, then page PagerDuty if nobody acknowledges within 10 minutes. Escalation steps that target PagerDuty go to every PagerDuty connection, regardless of routing. PagerDuty also acts as a safety net: if an email step cannot be delivered (nobody is on call, the recipient has not confirmed, or the email fails), SutramX triggers your first PagerDuty connection instead.

If you already keep schedules and escalation rules in PagerDuty, the simplest setup is to route your critical monitors straight to the service and let PagerDuty decide who gets woken up. Route lower-priority monitors to a chat channel instead, so PagerDuty only pages for things that need a human now.

Troubleshooting

• "PagerDuty responded 400": the integration key is wrong, or it is not an Events API v2 key. Copy it again from the service's Events API V2 integration.
• Pages open but never resolve: open the incident in SutramX and check its Notifications list for the recovery delivery and its error.
• No acknowledgement in PagerDuty: acknowledgements are only sent when the down alert reached PagerDuty, and only for the first acknowledgement of an incident.
• The connection shows Failing: the last 3 deliveries failed. Fix the key with Edit, then send a test.
• Nothing is paged for some monitors: check the connection's routing, and whether a maintenance window, quiet hours or a down parent dependency held the alert back.

Common questions

Can I set the PagerDuty severity per monitor?

No. Every incident is sent with severity critical. Use routing to send only the monitors that should page to PagerDuty, and use PagerDuty's own event rules if you need to change urgency there.

Who can connect PagerDuty?

Only the workspace owner can connect, edit or remove it. Tests never run automatically, because they create a real incident.

Does acknowledging in PagerDuty stop SutramX escalation?

No. The sync goes from SutramX to PagerDuty. Acknowledge in SutramX (the dashboard, or the Acknowledge button on one-click Slack alerts) to stop both.

Connect it in SutramX

1. Sign in to the SutramX dashboard and open Integrations & API in the sidebar, then the Integrations tab.
2. On the PagerDuty card, click Connect. Where you see "Connect with …", you just sign in and approve. Otherwise the card shows two or three short steps and one box to paste into.
3. Already have a webhook link? Paste it into the box at the top of the page and SutramX works out which service it belongs to.
4. SutramX sends a test straight away so you can confirm delivery before any real incident.
5. Optional: use Routing to send only some monitors or groups to this channel.

You can connect more than one PagerDuty destination. Each connection has its own routing, so different channels can receive different monitors.

Other incident and developer integrations

• GitHub issues alerts setup: Open an issue on downtime, close it on recovery.