How to Set Up an On-Call Rotation in PagerDuty
An on-call rotation in PagerDuty determines who is responsible for responding to production incidents at any given time. A well-configured rotation ensures coverage without burning out individual engineers, routes alerts to the right responders, and escalates automatically when the primary responder does not acknowledge.
This guide covers how to set up a sustainable on-call rotation in PagerDuty, configure escalation policies, and establish the rotation practices that prevent on-call from becoming a morale drain.
Step-by-step guide
Create a Schedule for your team
In PagerDuty, go to People > On-Call Schedules > New Schedule. Name it clearly: "Backend On-Call" or "Platform Primary." Add your team members as participants. Set the rotation type to "Weekly" for most teams (daily rotations create too much handoff overhead; biweekly can exhaust individuals). Set the handoff time to 9:00 AM on Monday in the responder's local timezone so rotation changes happen at the start of a working week, not at 3 AM on a Sunday.
Configure primary and secondary layers
Add a second schedule layer for the secondary (backup) responder. The secondary is notified if the primary does not acknowledge within a configured timeout. Use a different rotation offset so primary and secondary are never the same person. For example, if the primary rotates Monday→Monday, offset the secondary by 4 days so they shift Thursday→Thursday. This ensures each engineer is not simultaneously primary and secondary.
Build an Escalation Policy
Go to Services > Escalation Policies > New Escalation Policy. Level 1: notify the on-call schedule (primary). After 10 minutes without acknowledgment, escalate to Level 2: the secondary schedule. After another 10 minutes, Level 3: notify the engineering manager. Attach the escalation policy to your PagerDuty Service. The escalation policy is the spine of your incident response — every alert routes through it.
Configure alert routing and noise reduction
In your Service settings, configure alert grouping to merge related alerts within a 5-minute window into a single incident. Enable transient alert suppression for alerts that resolve within 2 minutes — these are usually self-healing conditions that do not need human intervention. Set quiet hours thresholds: for SEV3 alerts, configure a lower-urgency policy that notifies via email and Slack instead of phone call during 11 PM – 7 AM. Reserve phone calls for SEV1 and SEV2 only.
Add schedule overrides for PTO and holidays
Use PagerDuty's override feature (Schedules > your schedule > New Override) to cover on-call shifts when a team member is on PTO. Add overrides in advance — do not wait until the day before. Create a Slack reminder for the team to check and cover upcoming on-call gaps at the start of each month. Uncovered on-call shifts that fall to engineers unexpectedly are a major burnout driver.
Common mistakes
No escalation policy or escalation directly to the manager
Escalating directly from primary responder to manager (skipping a secondary) creates two problems: managers get woken up for incidents that a senior engineer could handle, and there is no safety net if the manager is also unavailable. Always have a secondary responder layer before escalating to management.
Alerting on every anomaly instead of actionable conditions
Alert fatigue is the single biggest driver of on-call burnout. Every alert should require a human decision or action. If the alert resolves itself or requires no action 80% of the time, suppress it or set it to low urgency. Audit your alert inventory quarterly and remove or demote alerts that are not actionable.
No on-call handoff process
Without a structured handoff, context about ongoing issues, flaky alerts, and recent deployments is lost each rotation. Require a written handoff document (can be a Notion or Confluence page) updated each week summarizing: current incidents, known flaky alerts, recent deployments to watch, and any unresolved issues from the rotation.
Tips
Pay on-call engineers a separate on-call allowance — it communicates that carrying the pager has real cost and makes on-call feel valued rather than a tax on employment
Track on-call interrupt metrics: alerts per week, time to acknowledge, incident duration. Show these in your weekly EM review so on-call load is visible and can be reduced proactively.
Set up a #pagerduty-alerts Slack channel where all PagerDuty incidents are mirrored — this gives the team visibility into production health without being paged themselves
How Vantage helps
PagerDuty manages who responds to incidents and when. Vantage connects the incidents being responded to with the product requirements and engineering tickets behind the affected services. When an on-call engineer resolves an incident, Vantage can surface the relevant PRD sections and acceptance criteria for the affected feature, giving responders product context alongside the technical alert data.