On-Call Management: Schedules, Escalation and Handover

On call is the arrangement by which a named person is responsible for responding to urgent problems outside normal working hours, or around the clock, for a defined period. When an alert fires or a customer reports a failure, the on-call person is the one who is paged. If they do not respond, the page moves on to someone else.

On-call management is the design and upkeep of that arrangement. It covers the schedule that says who is on call and when, the escalation policy that says what happens when a page is not answered, the exceptions that real life requires, the handover between shifts, and the care of the people who do the work. Done well, it is nearly invisible: the right person answers quickly, and nobody dreads the week. Done badly, it is the main reason good engineers leave.

This guide describes the components in the order a team builds them. It describes how Atlas supports each, and where it states a limit, that limit is real.

The three questions the system must answer

Any on-call system has to answer three questions, in the order people ask them. First, who is covering right now? A responder at three in the morning wants one name, not a spreadsheet to interpret. Second, when does it change? A manager reading on a Tuesday wants to see the shape of cover over the coming days. Third, where are the holes? An uncovered stretch is the failure that on-call management exists to prevent, and it should be impossible to miss.

The Atlas On call screen is organised around exactly these three questions. The name of who is covering now is at the top. A band shows every handover over today, 7 days or 14 days. Uncovered stretches are drawn in the band, with the ability to put someone on from the lane where the hole is. Setting up is deliberately kept apart, in a Set up panel at the bottom, so that the live page stays readable under pressure.

Component 1: the schedule

A schedule is a rule that produces a sequence of people over time. The simplest schedule is one rotation: a list of people who take turns, each for a day or a week. Rotation length is a trade-off. Short rotations spread the burden but increase handovers. Long rotations reduce handovers but can exhaust one person. A week is common for teams that are paged rarely. Teams that are paged often tend to prefer shorter shifts.

Real teams soon need more than one rotation. A common pattern is a weekday primary plus a separate weekend rotation. Atlas expresses this with layers. A schedule has one or more layers, each with its own members, its own rotation (daily, weekly or a custom number of hours) and its own anchor instant from which every handover is calculated as a whole number of rotations. Layers stack, and a later layer wins where it applies, so a weekend layer can sit above a weekday layer without creating a second schedule that someone will forget to update.

Time zones deserve care. A schedule in Atlas is tied to an IANA zone name, such as Europe/London, never to a fixed offset. A fixed offset silently breaks twice a year at daylight-saving changes and hands the pager to the wrong person on the two nights nobody expects. If your team spans zones, decide in which zone the schedule is read, and show people the handover in their own zone.

The schedule examples guide shows several patterns, including primary and secondary, follow-the-sun and business-hours-plus-weekend.

Component 2: the escalation policy

A page that nobody acknowledges is an outage that nobody is working on. An escalation policy is the ordered ladder that prevents it. Each step names who to alert and how long to wait for an acknowledgement before moving to the next step.

A typical ladder is: alert the primary on-call, wait five minutes, alert the secondary, wait five more, alert the team lead, and then the engineering manager. The waits should be short enough that a real emergency does not sit unnoticed and long enough that a person who is awake and responding is not interrupted by the next step.

In Atlas, an escalation policy has ordered steps, each with a wait in minutes and one or more targets. A target is a schedule, which resolves to whoever is on call at that moment, a person or a team. Targets that refer to a schedule matter because they follow the rota without anyone editing the policy. A policy can repeat, which gives a second full pass before the incident falls through to the workspace fallback list of responders. Deleting a schedule or a team degrades the policy to no target resolved, rather than blocking the delete or removing the policy during an outage.

Before you rely on a policy, test it. The Atlas simulator asks who an escalation would reach, without paging anyone. Use it after every change to a schedule or policy. For design principles, see the guide to designing an escalation path.

Component 3: alert sources

Pages originate from somewhere: a monitoring system, a health check, a customer report. Connect the sources deliberately and make each one carry enough context to act on. In Atlas, alert sources are signed inbound webhooks from your monitoring, which can declare and update incidents and, if you enable it, resolve them. A signature protects against anyone else posting a false page.

Each alert should answer: what is wrong, how bad is it, where do I look and what do I do first. An alert that says "CPU high" on a host is less useful than one that says that checkout latency has exceeded its threshold and links a runbook. The alert fatigue guide covers how to prune noisy alerts.

Component 4: overrides and exceptions

Schedules describe the normal case, and life is not normal. People fall ill, travel, swap shifts and take holidays. An override changes who answers for a period without changing the underlying rotation, which resumes afterwards. Make overrides easy, because a clumsy process leads to unrecorded verbal swaps, and then to a page sent to someone who is not expecting it.

An override can also say that nobody is on call for a window. That is an important thing to be able to say. Silently falling through to the rotation would page someone who had arranged not to be paged. Atlas records the override with a start, an end and a reason. Covering a hole and arranging an override are treated as response rather than configuration, so they sit beside the band on the live page. The guide to shift swaps and cover gives a short policy.

Component 5: handover

At each handover, the outgoing person transfers context: what is open, what is fragile, what changed recently and what to watch. Without it, the incoming person finds out about the half-fixed problem when it pages them. A short written handover costs five minutes and saves hours. The handover checklist guide provides a template.

Making on call sustainable

The ethical and practical core of on-call management is that being interrupted at night is costly. Studies of sleep disruption are not needed to know it: tired people make mistakes, and people who are woken often will eventually leave. Design the system to keep the burden fair and to reduce it.

• Measure the load: pages per shift, pages outside working hours and pages per person across a quarter. Distribute fairly, and look for people who carry more than their share.
• Reduce the noise. Each page should need a human. Convert pages that always resolve themselves into dashboards, and fix the causes of those that keep coming back.
• Give recovery time. A person woken for a long incident should have a morning off or a later start, without having to ask.
• Staff it adequately. A rotation of two people is a permanent burden. Many teams find that a rotation needs several people to be sustainable.
• Pay or compensate according to your jurisdiction and your agreements. Rules on working time and on-call pay vary by country and by contract, so confirm what applies to you rather than copying another company.
• Train newcomers by shadowing before they take the pager, and pair them with an experienced person for their first shift.

Connect on call to incident management

On call and incident management are two halves of one practice. The page brings in the responder and the incident record holds the work. In Atlas, a declared incident can trigger an escalation policy, and each page has a recorded outcome: pending, sent, acknowledged, failed, superseded or no target. Only the first acknowledgement counts for response time, so the figure cannot be improved by someone else opening the incident later.

Severity decides whether a page wakes anyone. Atlas distinguishes a page that wakes people and overrides quiet hours from a notification that does not and from a record that notifies nobody, set per severity level. See the incident severity guide.

Onboarding a new on-call engineer

Nobody should take their first page unprepared. Give each newcomer a short path. First, they read the incident response plan and the runbooks for the services they will cover. Second, they shadow an experienced person for a full shift, watching the pages and the responses without carrying the pager. Third, they take a shift as secondary, paged only if the primary does not answer. Fourth, they take a shift as primary with a named buddy to call.

Before the first shift, check the practical items: access to the systems and the incident tool, notification settings that wake them rather than failing silently, a charged phone and a known way to reach the escalation contacts. Run a test page at the start so that the first real one is not the first time they have heard it.

Tooling checklist

Whatever you use, check that your on-call setup can do the following. Each item has caused real outages when it was missing.

• Show who is on call now, in one place that responders can find under stress.
• Stack rotations, so that a weekend layer or a holiday layer can override the base rota.
• Hold a time zone name rather than an offset, and survive daylight-saving changes.
• Record overrides with a reason, including a deliberate gap.
• Escalate automatically when a page is not acknowledged, with a repeat and a fallback.
• Simulate an escalation without paging anyone.
• Accept alerts only from sources that can prove who they are.
• Keep the history of who was paged, when, and who acknowledged.
• Work on a phone, because that is where the page arrives.

Common failures

• A schedule with an uncovered gap, found when the page goes unanswered.
• An escalation policy that targets a person who left the company.
• Time zone errors at daylight-saving changes.
• A single point of failure: a policy with one step and no fallback.
• Overrides arranged in chat and not recorded.
• No testing. A policy that has never been simulated is an assumption.
• A rota that is fair on paper and unfair in practice because one service pages ten times as often as the rest.

Getting started in Atlas

Open On call. The name at the top is who is covering now. Read the band for the handovers ahead and choose Today, 7 days or 14 days. If a stretch is uncovered, put someone on from the lane where the hole is drawn. Open Set up at the bottom to create rotations, escalation policies or alert sources, and use the rotation editor to correct an existing rotation.

Everything on this screen is scoped to your workspace, including the cached answer, so switching workspace never shows the previous workspace's rota. On call is part of the Incident Management module, included from the Team plan. See the pricing page for plan details.