PagerDuty
Page the right person the moment a site goes down
Outages open a PagerDuty incident and recoveries resolve it. Your escalation policy does the rest.
Sentinel → PagerDuty
Why PagerDuty
Detection from Sentinel, escalation from PagerDuty
PagerDuty already knows who is on call, how long to wait before escalating, and which phone to ring. What it needs is a trustworthy signal. Sentinel checks every site from several regions and only opens an incident when the outage is real, then closes it the moment the site answers again.
Nothing to host and no webhook to write. The integration uses PagerDuty's Events API v2 directly, with the deduplication and resolve semantics PagerDuty expects, so the incident timeline reads the way an on-call engineer wants it to.
- Events API v2, one integration key per service
- Trigger on outage, resolve on recovery, per-monitor dedup keys
- Critical and warning severities mapped for your event rules
- Included on the Business plan
Incident #4127 · Storefront
Storefront: down (Service Unavailable (503))
- 12:51:12 Triggered by Sentinel critical
- 12:51:14 Notified on-call via phone
- 12:52:40 Acknowledged
- 12:57:03 Resolved by Sentinel
dedup_key sentinel-monitor-123-availability
Features
Built for the on-call rotation
Opens the incident, closes the incident
An outage triggers a PagerDuty incident against your service. When the site recovers, Sentinel resolves the same incident, so nobody closes pages by hand.
Deduplicated per monitor
Repeat failures while a site is down append to the open incident instead of paging again. A keyword failure and a hard outage on the same site stay separate incidents.
One key per service
Paste the Events API v2 integration key from the service you want paged. Connect several: one per client, one per escalation policy, one for staging that pages nobody.
Severity that PagerDuty understands
Hard outages, unreachable ports and missed heartbeats arrive as critical. Keyword, server-error and Lighthouse failures arrive as warning, so your event rules can decide who is woken up.
Deep links back to the evidence
Every incident links to the monitor and the Sentinel incident, with the failing region, the reason and the previous status in custom details.
Test before the outage
One click opens and resolves a test incident on the service. A rejected key is reported on the spot instead of being discovered at 3am.
How do I connect PagerDuty to Sentinel?
In PagerDuty, add an Events API V2 integration to the service you want paged and copy its integration key. In Sentinel, open your team's Integrations page, add a PagerDuty service, paste the key, and press Test. The whole thing takes about two minutes.
Does Sentinel resolve the incident when the site recovers?
Yes. Each outage carries a dedup key made of the monitor and the failure type, and the recovery sends a resolve event with the same key. PagerDuty closes the incident without anyone touching it.
Will I get paged twice for the same outage?
No. While an incident is open, further failures on that monitor append to it rather than opening a new one. Once it resolves, the next outage opens a fresh incident.
Can I keep some monitors off PagerDuty?
Yes. Every monitor has its own notification routing, and PagerDuty is a row in it. Untick it for staging sites or low-stakes monitors and they will still alert Slack and email without paging anyone.
Which plans include PagerDuty?
The PagerDuty integration is included on the Business plan. On Pro, custom webhooks can reach any on-call tool that accepts HTTP.
What about Opsgenie, Rootly or incident.io?
Those take Sentinel's signed webhook today. Point a webhook endpoint at their inbound URL and they receive the same open and recovery events as JSON.
Put PagerDuty downstream of real checks
Connect a service on the Business plan and test it in one click.
No card for the free plan · 14-day trial on paid plans · Cancel anytime