Cloud Parts

On-call

A rotation of engineers who carry the pager, so a real person answers when production breaks at 3 a.m.

1 technology on this page ↓

How it works

On-call means that, at any moment, a named engineer is responsible for responding to alerts for a service, usually within an agreed time: Google’s SRE book gives 5 minutes for user-facing systems and 30 minutes for less time-critical ones. A schedule rotates the duty through the team, often in week-long shifts, and many teams run a primary and a secondary. An escalation policy says what happens when nobody answers: page the primary at once, the secondary if there’s no acknowledgement within, say, 10 minutes, then a manager. Paging tools call, text and push to phones until someone acknowledges. Teams spread over time zones can hand the pager from site to site during each one’s daytime, “follow the sun”, so nobody covers nights. At each handoff the outgoing engineer writes down what happened and what is still open. Because waking people up is costly, healthy rotations put limits on it: enough people that each is on call only part of the time, a cap on how many incidents one shift should see, and pay or time off for out-of-hours duty. The pages themselves come from alerting; when one turns into something bigger, incident management takes over.

Think of it as

The duty doctor on a hospital ward. One person holds the bleep each night, a senior registrar is the backup if they don’t answer, and the morning handover tells the day team which patients to watch.

Reach for it when

  • Services whose users expect them to work outside office hours
  • Teams that build and deploy their own services and should feel the cost of their failures
  • Any system with an availability target someone is accountable for

Think twice when

  • Rotations of two or three people covering 24/7; they burn out, so widen the rotation, share it with another team or narrow the hours
  • Paging for things that can wait until morning; send them to a ticket queue instead
  • On-call without authority: the person paged must be allowed to roll back, restart and escalate

A real example

A team of eight runs a payments API. Each engineer is primary for one week and secondary for another every two months. The escalation policy pages the primary immediately, the secondary after 10 minutes without an acknowledgement and the engineering manager after 20. Last quarter the rotation averaged three pages a week, one of them at night; anyone paged overnight starts late the next day, and each Monday’s handoff note lists open issues for the next person.

Used for on-call

On-call is something products do, not a kind of product. These are often used for it, grouped by what they are.

The parts of a rotation#

Most paging tools, from PagerDuty to incident.io and Better Stack, model the same pieces.

Schedule

who, when

Layers of shifts, daily or weekly, that say who is on call at any moment, with overrides for holidays and swaps.

Escalation policy

if nobody answers

An ordered list of rules. The first target is paged immediately; if nobody acknowledges before the timeout, the next level is paged, until someone does.

Primary and secondary

backup

The secondary catches pages the primary misses, or takes the non-urgent work so the primary can focus on pages.

Handoff

end of shift

A short note to the next person: what fired, what was done, what is still open.

Follow the sun

time zones

Two or more sites each cover their own daytime, so nobody routinely works nights.

Shadowing

training

New engineers follow an experienced person’s shifts before joining the rotation themselves.

Paging tools in 2026#

The market has been moving. Check a tool’s status before building a rotation on it.

ToolStatusNotes
PagerDutyActiveFounded in 2009 by three former Amazon engineers; schedules, escalation policies, status pages
Atlassian OpsgenieEnd of sale 4 June 2025; shuts down 5 April 2027Customers are moved to Jira Service Management; data not migrated is deleted
Grafana OnCall (OSS)Maintenance mode March 2025; archived 24 March 2026Grafana points users to Grafana Cloud IRM
AWS Systems Manager Incident ManagerClosed to new customers since 7 November 2025Existing customers can keep using it; no new features
incident.io, Better StackActiveOn-call schedules and escalation sold alongside incident response and, for Better Stack, uptime monitoring

Often confused with

AlertingIncident management
Where it came from2006–2027

Operations staff carried pagers long before the web, but for years the people who wrote software were not the ones woken up by it. In a 2006 interview with Jim Gray, Amazon’s CTO Werner Vogels described the alternative: each service had a team “completely responsible for the service”, from design to operation. “You build it, you run it,” he said; giving developers operational duties brought them into contact with the day-to-day running of their software and with customers, and had “greatly enhanced the quality of the services”.

PagerDuty grew out of that culture. In January 2009 Alex Solomon, Andrew Miklas and Baskar Puvanathasan, who had worked at Amazon, started looking for internal tools that other companies would need. Baskar thought of being on call at Amazon, called “pager duty” because engineers carried literal pagers on their belts. Scheduling who is on call, and escalating when they don’t answer, became a product category of its own.

Google’s 2016 SRE book put numbers on what a humane rotation looks like. No more than 25% of an SRE’s time should go to on-call, which means at least eight engineers for a single-site 24/7 rotation with a primary and a secondary, or six per site for two sites. Since an incident takes about six hours to handle and follow up, a shift should see at most two incidents in 12 hours. It also recommends follow-the-sun rotations, because night shifts harm health, and compensation, in time off or cash, capped so that it limits how much on-call one person takes on.

Why it’s built this way

The builders carry the pager
When the people who write the code are the ones woken by it, reliability work stops being someone else’s problem. Vogels credited the practice with better services and a direct line to customers.
Escalate automatically
A phone on silent or a dead battery shouldn’t mean an outage goes unanswered. Escalation policies keep paging the next person until someone acknowledges.
Cap the load, not just the hours
Google sizes rotations so on-call is at most a quarter of anyone’s time and aims for no more than two incidents per 12-hour shift, leaving time to fix causes rather than only fight fires.
Follow the sun where possible
Splitting the day between sites in different time zones removes routine night shifts, at the cost of coordination between sites.

Timeline

  1. 2006

    Werner Vogels: “You build it, you run it”

  2. 2009

    PagerDuty founded in Toronto by three former Amazon engineers

  3. 2016

    Google’s SRE book sets out the 25% on-call limit and two incidents per shift

  4. 2025

    Opsgenie ends sales; Grafana OnCall OSS enters maintenance; AWS Incident Manager closes to new customers

  5. 2026

    Grafana OnCall OSS repository archived

  6. 2027

    Opsgenie scheduled to shut down in April

Sources10

Improve this page on GitHub