On-call rotations: how to set one up people can live with

On-call means one named person has agreed to respond to urgent alerts within a set time, during set hours, including hours when they are not at work. You need it when your service must work at night or at weekends and a person has to fix it when it breaks. If only one or two people could do that job, you are too small for a rota, and a "best effort" promise is the honest choice.

Three things separate on-call from "whoever sees it first":

• A name. At any minute, exactly one person is responsible, and everyone can look up who.
• A response time. For example: acknowledge within 5 minutes, be at a laptop within 15.
• Hours. The shift has a start and an end, and both are written down.

Who needs it

You need on-call when an outage outside working hours costs more than keeping someone ready. That is usually the case when customers pay you, use the service in the evening or at weekends, or were promised an uptime figure.

When the team is too small

Two people sharing a weekly rota are each on call for 26 weeks a year. People cannot keep that up. They leave, or they stop answering. With fewer than four people, do not run a full rota.

Use best effort hours instead, and say so in public: "We respond to outages from 08:00 to 20:00 UK time, Monday to Friday. Outside those hours we respond as soon as we can." Alerts still reach phones, but nobody has promised to answer at 03:00.

A promise you keep is worth more than a 24 hour promise you break.

The primary is the first person alerted. The secondary is the backup, alerted only when the primary has not acknowledged within a set number of minutes.

The secondary exists because the primary is a person. Phones run out of battery. People drive through tunnels, take showers and sleep through a quiet ringtone. Without a backup, one missed alert means nobody is working on the outage.

How the two roles differ

A common pattern is that this week's secondary becomes next week's primary. They have already heard what went wrong during the week, so the handover is short.

If the team is too small for a secondary, the backup is the engineering manager, and after that the whole team at once.

Most teams should start with a weekly rotation shared between at least four people. The other shapes solve particular problems: frequent pages, engineers spread across time zones, or weekends that differ from weekdays.

The examples in this guide use an imaginary team: four engineers (Maya, Ben, Aisha and Lukas) and their manager, Carol.

The minimums are rules of thumb, not laws. They come from simple arithmetic.

• Weekly, 4 people: 52 weeks divided by 4 is 13 weeks on call each, one week in four.
• Daily, 5 people: 365 days divided by 5 is 73 days each.
• Follow-the-sun, 3 sites: each site covers 8 hours of its own daytime, so nobody is paged at night. Two people per site is the least that lets one of them take leave.

Count leave as well. With four people and one away for two weeks, the other three are on call one week in three until they return.

A detail for daily rotations: with exactly 7 people, each person gets the same weekday for ever, and one of them always has Saturday. Use a number that does not divide into 7, or change the order every few weeks.

Whatever tool holds the rota must know the time zone. In PULSX, an on-call schedule has a time zone, shifts are daily, weekly or a custom length, and people rotate in a set order. It is one of the free features.

Swap at a fixed time in working hours, and have the outgoing person hand over a short written note. A good default is mid-morning on a Tuesday, for example 10:00.

When in the day to swap

• Not at midnight. Nobody is awake to hand over, and an incident running at 23:55 changes owner at the worst moment.
• Not on a Friday. The new person starts with a weekend and no warm-up.
• Not on a Monday, if your public holidays tend to fall on Mondays.

What to pass on

ON-CALL HANDOVER: Maya to Lukas, Tuesday 13 October 2026, 10:00

Open incidents
- None.

Pages this shift (4)
- Thu 03:40  Checkout health check failed. Database connections at
             the limit. Restarted the API. Real fix is ticket OPS-212.
- Sat 16:40  Same alert, same cause, same fix.
- Sun 09:05  Disk at 95% on the worker host. Cleared old exports.
- Mon 21:30  Certificate alert for a staging host. Should not page.
             Moved to the chat channel.

Still fragile
- The connection problem will come back before OPS-212 ships.
  Runbook: "Checkout health check failing", step 3.

Planned this week
- Wed 14:00  Database upgrade, maintenance window booked.
- Fri        Lukas is away for the day. Aisha covers (the override is
             in the schedule).

Muted alerts
- Worker queue length, muted until Wed 16:00 for the upgrade.

Two rules make the handover safe. The outgoing person stays on call until the incoming person says "I have it" in writing. And the incoming person sends a test alert to their own phone before the swap, so a broken notification setting is found at 10:00 and not at 03:00.

An escalation policy is the list of who is alerted next, and after how many minutes, when nobody acknowledges. A sound starting point is: the primary at 0 minutes, the primary again at 5, the secondary at 10, the manager at 20 and everyone at 30.

The example, played out

The outage had a person on it 13 minutes after the first alert, even though the primary never woke up.

How to pick the numbers

• Each gap must be long enough to wake up, read and tap. Five minutes is fair. Two minutes wakes the secondary while the primary is still finding their glasses.
• The whole ladder should finish within 30 minutes. If the last step is at 60, an unanswered outage runs for an hour before the team knows.
• The last step is everyone. It should almost never fire. If it does, review it the next day.

PULSX escalation steps work this way: after a set number of minutes with no acknowledgement, a step alerts the primary again, a named person, or everyone.

Page a person only when three things are true: something is broken now, it is hurting customers now or will within the hour, and a person can do something about it now. Everything else is a notification, and it can wait for working hours.

The two words are worth keeping apart.

• An alert (a page) interrupts one named person and asks for action now. It is allowed to wake them.
• A notification is information. It goes to a chat channel, an email inbox or a ticket, and somebody reads it when they are next at work.

Alert fatigue

Alert fatigue is what happens when most pages need no action. People learn that the sound usually means nothing, so they silence it, answer late or acknowledge without looking. Then the one real page is treated like the rest.

The cure is fewer pages, not more discipline. Each page that needed no action is a fault in the alert, and you fix the alert.

Three habits that keep pages rare

1. Retry before paging. One failed check is often a network blip. Page only after several failures in a row.
2. Page on what customers feel. "Checkout returns errors" is a page. "A server is using a lot of memory" is a cause to look at once you are awake. The API monitoring guide shows how to build a health check that reports the customer's view.
3. Review every page at handover. If a page needed no action twice in a row, turn it into a notification or delete it.

Use an override: one person covers a named span of time for another, and the normal order carries on afterwards. Do not rewrite the rotation every time someone is away.

An override has four parts: who is covering, who they cover for, the exact start, and the exact end. A reason helps the next reader.

Override
  Covering:  Lukas
  For:       Maya
  From:      Thursday 24 December 2026, 09:00
  Until:     Monday 28 December 2026, 09:00
  Reason:    Maya is away for Christmas

In return
  Covering:  Maya
  For:       Lukas
  From:      Saturday 9 January 2027, 09:00
  Until:     Monday 11 January 2027, 09:00

Rules that keep swaps fair

• Both people agree, and the schedule is changed. A swap that lives only in a chat message will page the wrong person.
• Pay back like for like. A weekend for a weekend, a public holiday for a public holiday.
• Plan leave early. Ask for holiday overrides at least two weeks ahead, so nobody is cornered.
• Illness is the manager's problem. A person who is ill should send one message. Finding cover is not their job.
• Share public holidays in turn. Keep a list of who covered which holiday last year, and start from the other end this year.

PULSX schedules have overrides in this form: one person covers a named time span for another, with an optional reason.

Acknowledging means telling the alerting system and the team "I have seen this and I am on it". It stops the escalation. It does not mean the problem is fixed.

Acknowledge only when you are able to act. Tapping the button and going back to sleep is worse than not answering, because it stops the backup being called.

The first 30 minutes

1. Minute 0 to 5: acknowledge.
2. By minute 15: be at a laptop, with a working connection.
3. Confirm it is real. Request the failing URL yourself, from a different network if you can.
4. Say so in writing. One line in the incident channel: "Ben here, I have the checkout alert, looking now."
5. Open the runbook for that alert and follow it.
6. Tell customers if they can see the problem. Post a first update on your status page. The status page guide has wording you can copy.
7. At minute 30 with no cause found, ask for help. Call the secondary. Asking early is the job, not a failure.

Afterwards, if the incident meets your triggers, it gets a written review. See how to write an incident postmortem.

What will really wake someone

Be honest about this before the first shift. An email does not wake most people. A chat message often does not either. A phone call usually does, and so does a loud push notification.

PULSX sends alerts by email, Slack, Discord, webhook and push to its Android app. It does not send SMS and it does not make phone calls. The Android push is the alert that reaches a phone. If your team needs a ringing call to wake up, you need a tool that makes calls.

Whatever you use, test it at night settings. Put the phone in the mode you sleep with, send a test alert and check that it makes a sound you would wake to.

A runbook is a short page that tells the on-call person what to do for one specific alert. Write it for someone who was asleep four minutes ago and did not build the service.

A good runbook has six parts: what the alert means, how to confirm it, the steps in order with exact commands, how to undo them, when to stop and escalate, and who to call.

RUNBOOK: Checkout health check failing

What it means
  https://shop.example/checkout/health returned something other than
  200 on four checks in a row. Customers probably cannot pay.

1. Confirm (1 minute)
  curl -sS -o /dev/null -w '%{http_code}\n' https://shop.example/checkout/health
  200 = it has recovered. Note it in the channel and watch for 10 minutes.
  503 = a dependency is down. Go to step 2.
  No answer = the API itself is down. Go to step 4.

2. Find the failing dependency (2 minutes)
  curl -sS https://shop.example/checkout/health
  Read the "checks" field: database, cache or payments.

3. Database shows "fail"
  Look at the connection count on the database dashboard.
  At the limit of 500: restart the API to release connections.
    deploy restart checkout-api
  Wait 2 minutes, then repeat step 1.

4. API is down
  Roll back to the last release:
    deploy rollback checkout-api
  Takes about 6 minutes. Then repeat step 1.

5. Payments shows "fail"
  This is the payment provider, not us. Check their status page.
  Post on our status page: "Card payments are failing."
  Do not restart anything.

Stop and escalate if
  - Two steps have not helped, or 30 minutes have passed.
  - Any step would delete data.
  Call the secondary. Then Carol.

Last tested: 2 September 2026, in staging, by Aisha.

The deploy commands are placeholders for whatever your own tooling uses. What matters is that the real command is written out in full, so nobody has to remember it.

Keeping runbooks true

• Put a "last tested" date on it. A runbook nobody has run is a guess.
• After every page, the person who handled it fixes whatever in the runbook was wrong or missing.

Being on call is work, even on a night when nothing happens, so it should come with pay, time back, or both. The exact rules depend on where you are and what your contracts say. This section is general practice, not legal advice.

A quiet shift still costs the person something. They stay near a laptop, keep the phone loud, do not drink much and do not go where there is no signal.

Arrangements teams commonly use

• A flat amount per shift for being available, paid whether or not anything pages.
• Extra pay for time worked on a page outside normal hours, counted from acknowledgement to the end of the incident.
• Time off in lieu. Hours worked out of hours come back as paid time off. Two hours at 02:00 becomes two hours, or more, off later.
• Rest after a night page. Someone who was up from 02:00 to 04:00 starts late the next day, without having to ask.
• A higher rate for public holidays.

What to settle before the first shift

1. Is on-call part of the job, or voluntary? Write down which.
2. What is paid for being available, and what for being called?
3. How is time back counted, and by when must it be taken?
4. Who can opt out, and for what reasons (for example caring duties or health)?

Put the answers in a document everyone on the rota can read. Then check them against your local employment rules with whoever handles those for you.

Count three things for every shift: pages per shift, pages outside working hours, and time to acknowledge. Look at them once a month. The targets below are rules of thumb to start from, not standards.

A month, worked through

The totals are 20 pages, 10 of them out of hours, and 12 that needed action. That is 60%, well below the 4 in 5 target.

Three things stand out, and each has a fix.

• Aisha's week had 11 pages and 7 needed no action. Five of the 7 were the same alert: disk at 80% on one host. It moves to a ticket. Without those 5, the month is 15 pages with 12 needing action, which is 80%.
• Her time to acknowledge rose to 7 minutes. That is what alert fatigue looks like in numbers. It is a fault in the alerts, not in Aisha.
• Maya did two weeks in a row. She covered the second one for Ben. The cover should be paid back, and the rota checked for the next 12 weeks.

Use these numbers to fix alerts and rotas. Do not use them to rank people.

Work through these 12 steps in order. Most of the time goes on writing runbooks.

1. Decide rota or best effort. Fewer than four people: publish best effort hours and stop at step 4.
2. List what can page. Start with three or four alerts that mean customers are affected now. Everything else is a notification.
3. Add retries to each alert, so a single failed check never pages.
4. Send notifications to a chat channel or email, not to the on-call person.
5. Pick the rotation shape and the swap time, for example weekly, Tuesday 10:00, in one named time zone.
6. Put the people in order, and enter leave you already know about as overrides.
7. Write the escalation steps with minutes: 0, 5, 10, 20, 30.
8. Write one runbook per paging alert, and link it from the alert.
9. Agree pay and time back in writing, before anyone takes a shift.
10. Test the whole chain. Break a test monitor on purpose. Check that the primary's phone makes a sound, then let it escalate and check the secondary's phone too.
11. Write a handover template, and use it at the first swap.
12. Book a monthly review of pages per shift, out-of-hours pages and time to acknowledge.

PULSX covers the tooling in this list for free: monitors that retry before alerting, on-call schedules, overrides and escalation steps, with 25 team seats. Create a free account, no card needed.