RETROSPECTIVE RECORD · PREPARED 16 SEPTEMBER 2026The archive · 200 retrospective records ↗

The archive / Support & operating load

Support & operating load / Operating entry · Entry note · prepared 16 September 2026

PagerDuty's own guide says on-call needs two people, not one

PagerDuty's own on-call documentation states that a rotation needs a backup person before any escalation policy makes sense.

Visual for this record: pagerduty-on-call-manager-handbook-guide
Visual published by response.pagerduty.com, shown for identification of the record. Credit: response.pagerduty.com · source page ↗ Rights: owner-review-pending.

The workload

PagerDuty publishes its own incident-response documentation, covering what a person on an on-call rotation is expected to do before, during and after an alert. The guide, aimed at teams running their own rotations rather than only at PagerDuty customers, spells out preparation tasks, a charged laptop, tested credentials, staggered notification timeouts, a triage-fix-improve-support cycle during an incident, and a handoff summary at the end of each shift. None of this assumes a large team; it assumes, at minimum, two people sharing the load.

What the documents show

Verified: PagerDuty's own Being On-Call page states as a scheduling recommendation to “always have a backup schedule,” adding “yes, this means two people being on-call at the same time,” and that a backup shift “should generally come directly after a primary shift” so context carries over. Verified: the same page recommends a five-minute escalation timeout, reasoning that someone who cannot acknowledge within five minutes is “probably not in a good position to respond to the incident anyway,” and describes a third escalation level, the entire team, as a rare fallback. Verified: a companion page on alerting principles separates alerts, which require immediate human action, from notifications, which should never wake anyone. This is PagerDuty's own recommended practice, drawn from its internal operations team, not an independent study of which on-call structures work best across companies.

The operating cost

Estimated: the guide's own minimum, a primary plus a backup, roughly doubles the number of people who need to be reachable at any given hour compared with a single person on call, without doubling the actual paging load. The documents state no dollar or hours figure for this; the estimate is based only on the headcount named in the recommendation itself.

The stop condition

Verified: the guide's own stop condition for scaling past two people is escalation to the whole team, which it describes as something that “should hopefully never happen.” For a solo operator with no second person available, the guide offers no structure below “backup schedule,” meaning the documented practice assumes at least one other reachable person exists; where that is not true, the guide's own recommendations do not directly apply, which is the limit of what these documents can support.

  • Who is the backup when there is no second employee: a co-founder, a contractor, or no one?
  • Does a five-minute escalation timeout make sense for a service where sixty minutes of downtime is tolerable?
  • What does “never hesitate to escalate” cost in practice when escalating means waking the only other person available?

PagerDuty's guide describes one vendor's recommended structure for on-call work, built around having more than one person to call; a one-person operation reading it is looking at a floor it cannot currently meet, not a menu it can freely choose from.

Sources & reading trail

Being On-Call — PagerDuty Incident Response Documentation ↗

States PagerDuty's own recommendations for backup scheduling, escalation timing and third-level escalation.

Source published: Not established · Retrieved: 16 September 2026

Alerting Principles — PagerDuty Incident Response Documentation ↗

Verifies PagerDuty's own distinction between actionable alerts and non-actionable notifications.

Source published: Not established · Retrieved: 16 September 2026

Vendor documentation, regulator records and founder-published documents establish the entry; the workload reading and the stop condition are Solo Product Office editorial analysis. This retrospective draft does not imply the site published on the event date.