On-call is a duty arrangement in which a named engineer is reachable for a defined period to respond to production alerts and incidents within an agreed response time. A good on-call setup combines a fair rotation, actionable paging alerts, clear escalation paths, runbooks and a sustainable workload so responders can restore service quickly.
What is on-call?
On-call means that a specific person is responsible, for a defined time window, for responding to problems in production. When an alert pages, the on-call engineer acknowledges it, assesses user impact, mitigates the issue or escalates it, and hands over cleanly at the end of the shift. On-call exists because software runs around the clock, while the people who understand it do not work around the clock.
On-call is not the same as being the only person who fixes things. The on-call engineer is the first responder and the coordinator of the first minutes. Their main goal is to reduce user impact quickly, which is why on-call quality directly shapes MTTR.
Common rotation models
| Model | How it works | Fits |
|---|---|---|
| Weekly rotation | One primary engineer per week, handover on a fixed weekday | Small teams with moderate alert volume |
| Primary / secondary | A secondary responder takes over if the primary does not acknowledge in time | Critical services, larger teams |
| Follow-the-sun | Shifts move across time zones so nobody is paged at night | Distributed organizations with teams in several regions |
| Business hours plus escalation | Responders during working hours; out-of-hours pages only for severe incidents | Internal tools and lower-tier services |
Whatever model you choose, define it explicitly: who is on call, how quickly they must acknowledge, who the escalation contact is, and how handover works. Ambiguity is what turns a minor alert into a long incident.
What should page a human?
The single most important rule: a page must be urgent, actionable and tied to user impact. If nobody needs to act within minutes, it belongs in a ticket queue, not on a phone. Symptom-based alerts on golden signals and SLO burn rate fit this rule well; alerts on every CPU spike do not.
The Google SRE book suggests concrete limits for sustainable on-call: SREs should spend no more than 25 percent of their time on call, and a shift should see on average no more than two incidents per 12 hours, because each incident needs time for diagnosis, mitigation and follow-up. Teams that exceed these limits drift into alert fatigue, missed pages and burnout.
Example: an escalation policy
An illustrative policy for a payment service could look like this:
- Severity 1 page goes to the primary on-call engineer by push notification and phone call.
- No acknowledgement after 5 minutes: page the secondary.
- No acknowledgement after 15 minutes: page the engineering manager on duty.
- Once acknowledged, the responder opens an incident, links the alert, the relevant dashboard and the runbook, and posts a first status update within 15 minutes.
Lower severities create a ticket and notify the team channel without waking anyone. The exact timings depend on your SLOs; what matters is that they are written down and tested.
Best practices
- Every alert has an owner and a runbook. Responders should never have to guess what an alert means at 3 a.m.
- Review pages weekly. Count pages per shift, mark each as actionable or noise, and delete or tune the noise.
- Protect handovers. A short written summary of open issues, recent deploys and ongoing mitigations prevents context loss.
- Compensate and rest. Pay or time off for on-call, and recovery time after a night incident, keep the rotation sustainable. Local labor law may set binding rules on standby and rest periods.
- Train before the first shift. Shadow shifts and game days build confidence before someone carries the pager alone.
- Close the loop. Significant incidents get a blameless postmortem with action items that reduce future pages.
Measuring on-call health
Treat on-call as a system you can observe. Useful indicators are pages per shift, the share of pages that were actionable, time to acknowledge, the number of night-time pages, and how many incidents needed escalation. Track them per team and per service, and review the trend in a monthly operations review. A rising night-page count or a falling actionable share is an early warning that the rotation is becoming unsustainable, long before people start to leave. Ask responders after each shift what slowed them down: missing dashboards, unclear runbooks or noisy alerts are usually cheap to fix.
Common mistakes
- Paging on causes (high CPU, one failed pod) instead of symptoms users notice.
- Rotations with too few people, so engineers are on call every other week.
- Escalation paths that exist only in someone's head.
- Treating on-call as pure firefighting and never investing in fixes that remove recurring alerts.
How Obseria helps
Obseria groups related alerts into a single problem with affected services and probable root cause, so the on-call engineer gets one page instead of twenty. Incident management in Obseria tracks timeline, responders and status updates, and Obseria Intelligence can start an agentic root-cause investigation with a chain of evidence while the responder is still opening a laptop. Workflows in Obseria Automation can run safe runbook steps automatically.