A three-person rotation cannot staff a second on-call tier the way a larger team can. There is no fourth engineer to promote into a backup schedule, no follow-the-sun handoff, and no separate operations group to absorb the page when the primary does not answer. The escalation policy has to be built around what the team can actually guarantee: a bounded acknowledgement window, a named fall-through, and a written decision about what happens when nobody answers.
The useful move is to treat the missed page as a design input rather than a failure to be prevented. The policy should answer two separate questions. First, how long does the first responder get before the page moves? Second, who receives it when it moves? Those are different decisions, and changing one without the other produces either a policy that escalates too early or one that never escalates at all.
Start with the acknowledgement window
PagerDuty’s operations team recommends a five-minute escalation timeout, on the reasoning that someone who cannot acknowledge within that window is probably not in a position to respond. Their guidance is explicit: “We recommend you set your escalation timeout to 5 minutes. This should be plenty of time for someone to acknowledge the incident if they’re able to. If they’re not able to within 5 minutes, then they’re probably not in a good position to respond to the incident anyway” (PagerDuty, Being On-Call).
That recommendation is made in the context of a team that has a backup schedule. It is evidence to read, not a rule to apply unchanged. Google’s SRE book describes typical paging response times as five minutes for user-facing or otherwise highly time-critical services and thirty minutes for less time-sensitive systems (SRE Book, Chapter 11). The gap between those two figures is the gap between a service whose downtime budget is measured in minutes and one whose budget is measured in hours. A three-person team running a service with a relaxed SLO can choose a longer window without violating anything. What it cannot do is leave the window undefined and hope the first responder always answers.
The timeout and the notification ladder are separate decisions. The timeout is a promise about how long the first responder has. The ladder is how hard the system tries to reach them inside that window. PagerDuty’s recommendation is to use push notifications and email first, then phone or SMS each minute after that until the escalation time, with escalation away from the responder if they do not pick up by the third call (PagerDuty, Being On-Call). For a three-person team, the ladder matters more than the timeout, because the first responder is often the only person who can act and the cost of a missed page is a longer outage rather than a handoff to a waiting backup.
Name the fall-through, and be honest about its limits
PagerDuty’s guidance is to always have a backup schedule, meaning two people on-call at the same time, and to place the backup shift directly after the primary shift so context can be passed on (PagerDuty, Being On-Call). A three-person team can do this in a limited way. If the rotation is weekly, the person who just finished a shift can serve as the named fall-through for the person starting. That gives the incoming primary a specific human to contact rather than a random member of the team, and it gives the outgoing primary a reason to hand over context rather than disappear.
What a three-person team cannot do is guarantee that the fall-through is awake. The fall-through is a named person, not a staffed tier. The policy should say so. PagerDuty’s own guidance acknowledges that the on-call engineer should not be expected to acknowledge every alert, because commutes and other necessary distractions are facts of life, and that this is what the backup on-call and schedule exist for (PagerDuty, Being On-Call). In a three-person rotation, the same logic applies to the fall-through. They may be asleep, in a meeting, or on a train. The policy’s job is to move the page to the next person rather than to assume the fall-through will answer.
PagerDuty suggests that the third level of escalation, after the backup schedule, should probably be the entire team, and notes this has happened once in the history of their operations team (PagerDuty, Being On-Call). For a team of three, the entire team is two other people. That is a small enough group that the third page is not a tier in any meaningful sense. It is a last resort, and the policy should describe it as one. The value of naming it is not that it will be used often. The value is that the first responder knows the page will not simply stop if they miss it, and the person who receives the third page knows they are receiving it because the first two did not answer, not because the system is confused.
Make the alert content carry its weight
Alert content is part of the escalation policy, not a separate concern. A page that reaches the second or third person without a metric, a description of the problem, and a runbook link has already spent the escalation budget without giving the responder anything to act on.
PagerDuty’s alerting principles define an alert as something requiring a human to perform an action, and say notifications should not be waking people up under any circumstance (PagerDuty, Alerting Principles). The same page states that anything waking a human in the middle of the night should be immediately human actionable, and that alerts not meeting this should be adjusted so they do not page at those times. For a three-person team, this is the cheapest available reduction in escalation load. An alert that pages at 03:00 and turns out to be a disk at 80% with 48 hours of headroom has consumed a night of sleep and produced no action.
The content guidance is specific. A descriptive, concise title. The triggering metric in the body. A description of the actual problem and why it matters. Clear resolution steps or a runbook link. PagerDuty’s example contrasts a useless title (“ALERT: Something went wrong”) with a useful one (“Disk is 80% full on prod-web-loadbalancer-af5462ce”), and pairs the metric with a plain-language explanation of the consequence (PagerDuty, Alerting Principles). A three-person team that writes alerts this way gives the fall-through a chance to act without first reconstructing what the alert means.
Testing is the other half. PagerDuty states that an untested alert is equivalent to not having an alert at all, and that testing should be included in release planning and deployment efforts (PagerDuty, Alerting Principles). For a small team, the practical form of this is a scheduled test of the escalation path itself: fire a synthetic page, let it escalate through the ladder, and confirm that each step reaches the intended person. An escalation policy that has never been exercised is a document, not a control.
Write the handoff into the policy
The handoff is where a small rotation either accumulates context or loses it. PagerDuty’s guidance is that when going off-call, the outgoing engineer should provide a quick summary to the next on-call about any issues that may come up during their shift, and that a verbal summary is generally sufficient (PagerDuty, Being On-Call). The same page notes that if an issue comes up during your on-call shift for which you got paged, you are responsible for resolving it, even if it takes three hours and there is only one hour left of your shift, and that you can hand over to the next on-call if they agree but should never assume that is possible.
For a three-person team, the handoff is also the moment when the fall-through arrangement is confirmed. If the outgoing primary is the named fall-through for the incoming primary, the handoff is the point at which both people know it. An unresolved issue that is handed over with a short summary is cheaper than one that is sat on until the next shift discovers it independently. The policy should say that unresolved issues are handed over, not held.
Google’s SRE book on managing incidents describes a clear, live handoff in which the outgoing commander states explicitly that the incoming person is now incident commander and does not leave the call until receiving firm acknowledgment (SRE Book, Chapter 14). That is a heavier protocol than a three-person team needs for routine shift changes, but the underlying principle transfers: the handoff is explicit, and the person receiving it acknowledges it. A verbal summary at the end of a shift is enough if both people know it happened.
Decide when the page becomes an incident
Escalation and incident declaration are related but distinct. Escalation moves a page from one person to another. Incident declaration changes the mode of response. Google’s SRE book recommends declaring an incident early rather than spinning up the incident management framework hours into a growing problem, and gives example conditions: needing a second team to fix the problem, an outage visible to customers, or an issue unsolved after an hour of concentrated analysis (SRE Book, Chapter 14).
For a three-person team, the second condition is the one that matters most. If the outage is visible to customers, the team is already in an incident whether or not anyone has declared it. The policy should say who declares it and what changes when they do. Google’s guidance is that the operations team should be the only group modifying the system during an incident (SRE Book, Chapter 14). In a three-person team, that usually means the person who acknowledged the page is the one making changes, and the other two are advising, researching, or preparing a rollback. The policy should make that division explicit so that a well-meaning teammate does not start changing production while the responder is mid-diagnosis.
Connect escalation to recovery drills
Some pages cannot be resolved by one person. A PostgreSQL restore that requires replaying WAL from a base backup is a multi-step operation, and PostgreSQL’s documentation is direct about the prerequisite: “To recover successfully using continuous archiving (also called ‘online backup’ by many database vendors), you need a continuous sequence of archived WAL files that extends back at least as far back as the start time of your backup. So to get started, you should set up and test your procedure for archiving WAL files before you take your first base backup” (PostgreSQL Documentation, Continuous Archiving and PITR).
The same documentation notes that if the archive command or library fails repeatedly because some aspect requires operator intervention or the archive runs out of space, the pg_wal/ directory will continue to fill, and that if the file system containing pg_wal/ fills up, PostgreSQL will do a PANIC shutdown (PostgreSQL Documentation). It advises monitoring the archiving process to ensure it is working as intended, and notes that if archiving falls significantly behind, it increases the amount of data that would be lost in a disaster.
Those are escalation-relevant facts. A failed archive is not a page that one person can resolve by restarting a service. It is a page that requires a second person to verify the archive state, confirm the base backup, and decide whether to continue the restore or stop and preserve evidence. The escalation policy should name that case: when a page involves a data restore, the fall-through is not optional. The person who receives the page should wake the fall-through before beginning the restore, not after discovering that the WAL sequence is incomplete.
This is also where the recovery checklist earns its place. Writing the steps down before the incident means the responder is not reconstructing the procedure at 03:00. The Recovery Checklist Before You Need It covers the same principle for backup and restore drills: the checklist is the artifact that lets a small team act without a dedicated SRE function.
Write the decision record
The most useful artifact for a three-person team is not the escalation policy itself. It is the decision record behind it: the timeout chosen, the fall-through order, and the conditions under which the team agreed to revisit the policy. Without that record, the next person to be woken at 03:00 will re-litigate the same question under worse conditions.
The record does not need to be long. It needs to state the timeout and why it was chosen, the fall-through order and how it rotates, the conditions under which the third page fires, and the trigger for revisiting the policy. A reasonable trigger is a change in team size, a change in the service’s SLO, or a missed page that reached the third level. The record should also note what the policy does not promise: that the fall-through is always awake, that the third page will always be answered, or that a three-person rotation can sustain the same response times as a larger team.
Google’s SRE workbook states that the overall goal of being on-call is to provide coverage for critical services while making sure reliability is never achieved at the expense of an on-call engineer’s health, and that psychological safety is vital for effective on-call rotations, with on-call engineers supported by procedures and escalation paths (SRE Workbook, Chapter 8). A written decision record is one of those procedures. It tells the person who is about to be paged that the team has already thought about what happens if they do not answer, and that the answer is not “someone will figure it out.”
What the policy should not claim
A three-person escalation policy should not claim to provide a second tier in the sense that a larger team does. It should not claim that the fall-through is always available. It should not claim that the third page is a routine step. It should not claim that the team can sustain the same response times as a team with a dedicated backup schedule.
What it can claim is narrower and more useful. The first responder has a defined window. The page moves to a named person if that window expires. The alert carries enough context to act on. The handoff is explicit. The decision record explains the reasoning. And the team has agreed on the conditions under which the policy is revisited. That is a policy a three-person team can actually keep.
FAQ
Should a three-person team use a five-minute escalation timeout?
Five minutes is PagerDuty’s recommendation for teams that have a backup schedule, and it is a reasonable starting point for a user-facing service with a tight SLO. For a service with a relaxed SLO, Google’s SRE book describes thirty minutes as a typical response time for less time-sensitive systems. The right choice depends on the service’s downtime budget, not on the size of the team. What matters is that the timeout is written down and tested.
Who should be the fall-through in a three-person rotation?
The person who just finished the primary shift is the natural fall-through, because they have the most recent context and PagerDuty’s guidance recommends placing the backup shift directly after the primary shift. If the rotation is weekly, that means the outgoing primary is the named fall-through for the incoming primary. The policy should state that the fall-through is a named person, not a guarantee that they are awake.
What happens if the fall-through does not answer either?
The third page goes to the remaining team member. PagerDuty describes the third level of escalation as the entire team and notes it has happened once in the history of their operations team. For a team of three, this is a last resort rather than a tier. The policy should say so, and the decision record should note that a third-level page is a trigger for revisiting the policy.
How does this interact with backup and recovery drills?
A page that involves a PostgreSQL restore is not a single-responder event. PostgreSQL’s documentation requires a continuous sequence of archived WAL files extending back to the base backup, and advises testing the archiving procedure before taking the first base backup. The escalation policy should name data restores as a case where the fall-through is woken before the restore begins, not after the WAL sequence turns out to be incomplete.
How often should the escalation policy be tested?
PagerDuty states that an untested alert is equivalent to not having an alert at all. The practical form for a small team is a scheduled synthetic page that exercises the full ladder, including the fall-through and the third level. The frequency is a tradeoff between confidence and disruption; a quarterly test is a common starting point, and the decision record should state the chosen interval and the reason for it.