Question 1

What does pagerduty do and why does every engineering team seem to use it?

Accepted Answer

PagerDuty occupies a specific place in engineering infrastructure that becomes obvious the first time you're responsible for a system that has to run continuously and something goes wrong at 2 a.m.

The product is an incident management platform. Its core job is to receive signals from monitoring systems — alerts that say something in your infrastructure is broken or degraded — and route those signals to the right person or team quickly enough to minimize downtime. The reason every engineering team seems to use it is that the alternatives — someone monitoring a dashboard manually, or alerts going to a shared email inbox that no one is watching overnight — break down as soon as systems are complex enough that things go wrong at unpredictable times.

PagerDuty works by sitting between your monitoring tools and your people. You connect alerting systems — this might be Datadog, New Relic, CloudWatch, Prometheus, or dozens of other monitoring platforms — and configure rules about what kinds of alerts should trigger what kinds of responses. When an alert fires, PagerDuty creates an incident and notifies the on-call person through whatever combination of push notification, SMS, phone call, or email is configured. The escalating notification sequence is deliberate: if the first person doesn't acknowledge within a defined time window, the alert escalates to the next person or team. This escalation chain ensures that a critical incident doesn't silently sit unacknowledged because the primary on-call person missed a notification.

The on-call scheduling system lets engineering teams define who is responsible for responding to incidents at any given hour, across days of the week and including holidays and time zones. Teams can set up rotations where responsibility cycles through team members on a weekly basis, so no single person carries the burden of being on-call indefinitely. Those schedules also handle override logic for vacations or days off.

Beyond the notification and escalation layer, PagerDuty provides an incident response workflow. When an incident is created, responders can acknowledge it, add notes, create conference calls, notify stakeholders, and resolve it all within the platform, which creates a documented timeline of what happened and what was done. That documentation matters both for post-incident review and for compliance purposes in environments where audit trails of system incidents are required.

The reason it's standard in engineering teams specifically is that the alternatives have well-known failure modes. Manual monitoring doesn't scale to systems that need to be watched continuously. Email-based alerting produces massive noise that people learn to ignore. Custom notification scripts are fragile and require maintenance. PagerDuty solves a specific, well-defined problem reliably enough that it became the default choice for teams that can't afford for incidents to go unnoticed. On most plans, the core incident notification and on-call scheduling features are available from the entry tier, though advanced features like event intelligence and automated runbooks sit at higher price points.

Question 2

How does on-call rotation scheduling work in pagerduty?

Accepted Answer

On-call rotation scheduling in PagerDuty is one of its most practically useful features, and understanding how it's structured helps you configure it in a way that's actually fair and functional for your team rather than just technically operational.

The fundamental building block is a schedule, which defines who is on-call during which time windows. A schedule in PagerDuty is composed of one or more layers, where each layer represents a set of users and a rotation pattern. The simplest configuration is a single layer with weekly rotations — each person in the layer is on-call for one week at a time, and the rotation cycles through the list automatically. When person A's week ends, the schedule automatically shifts to person B without any manual intervention required.

For teams that want more granular coverage — for example, distributing on-call duties by day of week rather than by full week, or separating weekday coverage from weekend coverage — PagerDuty supports multiple layers within a single schedule. You might configure a weekday layer where the on-call responsibility rotates daily among your team, and a separate weekend layer that rotates on a weekly basis, with different people or different rotation periods for each. The layers can also be restricted to specific time windows using the time restrictions feature, so a layer only applies during business hours, or only after midnight, giving you precise control over who is responsible when.

Escalation policies are a separate but closely related concept that's worth understanding alongside schedules. An escalation policy defines what happens when an incident isn't acknowledged within a time window. A typical escalation policy might say: notify the current on-call person from Schedule A; if they don't acknowledge within fifteen minutes, notify the engineering manager; if they don't acknowledge in another fifteen minutes, notify the VP of Engineering. Schedules and escalation policies are linked — you attach a schedule to a step in an escalation policy — and the combination gives you both the rotation logic and the fallback logic in one configuration.

Override management is particularly important for making on-call rotation sustainable for real teams. When someone is on vacation, traveling, or unavailable during their scheduled on-call week, they can create an override that temporarily assigns their on-call responsibilities to another person for that specific window. Overrides don't change the underlying schedule — when the override period ends, the original rotation resumes — which avoids the messy situation of having to reconfigure the whole schedule every time someone is unavailable.

Time zone handling is handled at the user level in PagerDuty, with each team member's notifications going out in their local time, which matters for distributed teams where team members are genuinely spread across multiple time zones. The schedule view itself can be displayed in any time zone, which is useful for managers who need to understand coverage gaps across a globally distributed team. Most of these scheduling features are available across PagerDuty's standard plans, though some of the more advanced scheduling automation features are tier-dependent.

Pagerduty discussions

Discussions

What does pagerduty do and why does every engineering team seem to use it?

How does on-call rotation scheduling work in pagerduty?