We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Reliability Resilience
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Datadog trips a monitor at 03:12. By 03:12:30 the on-call engineer's phone is ringing. In between, PagerDuty received the event, matched it to a service, looked up the escalation policy, and fanned out notifications to phone, SMS, push, Slack, and Jira simultaneously.
PagerDuty processes over 4 million events per year across its customer base. The Events API v2 accepts payloads from more than 650 integrations. That single API endpoint is the standard for alert ingestion because it is dead simple: one POST with a routing key and a payload. The routing key is all the source system needs to know. Everything else (teams, schedules, escalation policies, notification channels) is configured inside PagerDuty.
This lesson covers how PagerDuty works as an integration hub, not just a paging tool. The webhook architecture, the bidirectional sync, and the patterns that make it the coordination backbone for most enterprise on-call teams.
PagerDuty is built around three core abstractions that make the integration model work.
| Abstraction | What it is | Why it matters |
|---|---|---|
| Routing key | A token that maps a source to a PagerDuty service | Source systems only know the key, not the team or schedule |
| Service | A logical unit that owns incidents | Each service has one escalation policy attached |
| Escalation policy | A chain of responders with timeouts | Determines who gets paged and when they escalate |
The flow is: ingest event, match service by routing key, look up escalation policy, fan out to human notification channels and outbound webhooks. Outbound webhooks are what make PagerDuty a hub instead of just a paging app. The incident shows up in Slack, Jira, and Statuspage within the same second.
The routing key abstraction is the design decision that makes PagerDuty scale. Source systems do not need to know about teams, schedules, or escalation policies. A single PagerDuty account can handle alerts from 650 different integrations without the integrations knowing anything about each other.