What Does On-Call Mean?

Last verified on Nov 8, 2026.

Being on-call means you are the person designated to respond when production breaks. During your shift you can be reached by a page and are expected to act on production systems within an agreed number of minutes. Outside your shift, you are not.

The role matters because someone has to notice and act quickly when an SLO is at risk, and because the design of the rotation decides whether people stay on a team.

What the Shift Involves

Google's SRE book describes the duty this way. When paged, the engineer acknowledges, triages the problem, and works toward resolution, bringing in teammates and escalating when needed. Pages take priority over almost everything else, including project work. Lower-priority alerts and releases can be handled during business hours.

The response time is a team decision tied to availability. Google gives typical values of 5 minutes for user-facing or highly time-critical services and 30 minutes for less time-sensitive ones. A service with a 99.99% quarterly target can be down for roughly 13 minutes in that quarter, so a reaction time of minutes follows directly from the target.

Primary, Secondary, and Escalation

Many teams run two layers. The primary takes pages. The secondary is a fall-through for pages the primary misses, or handles non-urgent production work, depending on the team. Where a separate secondary is not needed, two related teams can serve as each other's secondary.

Google lists three resources that make on-call manageable: clear escalation paths, well-defined incident-management procedures, and a blameless postmortem culture.

Keeping the Load Sustainable

Google uses numbers you can copy as starting points:

The workbook also says that 24 hours of on-call without relief is not sustainable, and that overnight 12-hour shifts are better than 24-hour ones.

If the pager load is above the budget, the cause is usually the alerts. Google says paging alerts should line up with symptoms that threaten the SLO and should all be actionable, and warns that low-priority alerts firing hourly produce fatigue that causes real problems to get less attention. Read more under alert fatigue. Google also lists compensation for out-of-hours work as something to decide up front, through time off or cash, with a cap that works as a limit on how much on-call any one person takes on.

Preparing for a Shift

• Read the playbooks. A runbook or playbook only helps if on-callers know it exists. Google suggests exercises such as Wheel of Misfortune to keep that knowledge fresh.
• Check the handoff. Know which incidents are open and which changes are scheduled.
• Test your page. Confirm the device and the escalation path work before you need them.
• Know your severity scale. The incident severity levels decide who gets woken up.

Routing Pages to Your On-Call Tool

Most teams send alerts to a dedicated paging service. The PagerDuty, incident.io, and Rootly pages cover how those connect to Sazabi. Sazabi, an AI-native observability and security platform, can send issue notifications to PagerDuty, incident.io, Rootly, Slack, Microsoft Teams, or a webhook, optionally filtered by severity, so only the severities you pick wake someone. With the incident.io connector, the Sazabi agent can also check on-call schedules and escalation paths while you investigate.

Frequently Asked Questions

What does being on call mean?

You are designated to respond to production alerts and outages during a set period, and you can act on production systems within an agreed number of minutes of being paged. Outside that duty you work normal hours.

What is the difference between primary and secondary on-call?

The primary takes the pages. The secondary is a backup, either catching pages the primary misses or handling non-urgent production work, depending on the team. Google notes some teams swap secondary duty with a neighboring team instead of keeping a separate rotation.

How many pages per shift is too many?

Google SRE targets a maximum of two incidents per on-call shift so there is time for follow-up work such as postmortems. Above that, treat the pager load as a defect to fix.

How fast do you have to respond to a page?

The team and the service owners agree on it. Google describes typical values of 5 minutes for user-facing or time-critical services and 30 minutes for less time-sensitive systems.

Sources

1. On-call engineers are available within minutes per agreed paging response times (typically 5 minutes for user-facing services, 30 for less time-sensitive ones); primary and secondary rotations; the 25% on-call rule; two incidents per 12-hour shift; compensation; escalation paths as a key resource (accessed Nov 8, 2026)
2. A maximum of two incidents per on-call shift, playbooks for alert response, actionable alerts, and the 12-hour shift discussion (accessed Nov 8, 2026)
3. Emergency response is the work an on-call engineer does after a page (accessed Nov 8, 2026)
4. On-callers need to know playbooks exist, and practice exercises keep the knowledge current (accessed Nov 8, 2026)
5. The incident.io connector lets the Sazabi agent check on-call schedules and escalation paths (accessed Nov 8, 2026)
6. Sazabi issue notifications can be routed to PagerDuty, incident.io, Rootly, Slack, Microsoft Teams, or a webhook, optionally filtered by severity (accessed Nov 8, 2026)