Many founders first think seriously about night cover after an incident that nobody noticed until the morning. The obvious fix is to point the alerting tool at the most experienced engineer’s phone and ask them to keep it by the bed. That works for a few weeks but not for years. Below are the figures we recommend for sustained 24/7 on-call (a named engineer ready to respond to alerts at any hour), and the reasoning behind them.
Start with the arithmetic
A week has 168 hours. Split into eight-hour shifts, round-the-clock cover is 21 shifts a week, every week, including holidays and sick days. Each shift needs someone who can be reached, has access to production (the live systems your customers use) and knows the system well enough to act.
Does every service need 24-hour cover?
In our view, not every service does. Full 24-hour cover is costly, both in money and in the wellbeing of the people on the rota, so we recommend justifying it by business risk. There are four common patterns.
| Pattern | Hours | In practice |
|---|---|---|
| Business hours | 8am to 5pm | Closer to being on duty at work than on call |
| Daytime | 6am to 8pm | A longer day, still no night pages |
| Daylight follow-the-sun | About 21 hours | Two sites in different time zones hand over, so nobody works late nights |
| Full 24-hour | All day, every day | Best run follow-the-sun, or with time off in lieu and flexible hours |
A useful exercise is to list your services and ask, for each one, what happens to customers and revenue if it fails at 3am and nobody looks until 9am. Batch jobs and services that degrade gracefully (keep working in a reduced form) need less cover, because a few hours’ delay costs customers little. Check local labour law too, since it may limit how much out-of-hours work you can ask of people.
Decide how fast someone must respond
The second decision is response time, meaning how quickly someone must be at a keyboard working on the problem, not how quickly it is fixed. The right tier depends on the financial and reputational damage of a failure, your reliability target, any regulation you are under, and whether automated fixes already exist. A response of three minutes or less needs at least two engineers ready at the same moment, so one can step away for basic needs. Five minutes is only slightly more forgiving: you still need handovers around commuting and a clear order of who is paged first and who is paged next. At 30 minutes or more, on-call engineers can commute, run errands or eat out, and may not even need to carry a laptop.
What a sustainable load looks like
Our rule of thumb is that an engineer should handle no more than about two incidents per shift, assuming each takes four to six hours. Above that, fixes slow down, investigations get shallower and alert fatigue sets in (pages are missed or delayed because there are too many of them). We also recommend keeping operational work, such as pages, tickets and manual fixes, to no more than 50% of an engineer’s time, and on-call to no more than 25%. Treat these as limits, not targets. Too little load is also a problem: responders lose familiarity with the system, and a service that rarely pages may be better looked after by its own developers.
How many people that takes
Our minimum for a single-site team that is on call at night is eight on-callers. For a two-site follow-the-sun team, it is six engineers at each site. The reason is that 21 shifts a week have to be covered through holidays, sick days and departures while keeping every person inside the limits above. A lone SRE (site reliability engineer: someone whose job is keeping production running) is a single point of failure and cannot sustain the rota; without headcount for a small team, sharing responsibility across developers is the better choice. We also recommend keeping one spare person beyond the minimum.
Each shift should have a primary and a secondary (a first responder and a named backup), so a page the primary misses rolls over to someone else automatically. Without that, a single missed page can sit unanswered until morning.
Hiring takes longer than you think
Google has published a worked hiring example based on its own assumptions: about 12 weeks to find and onboard each SRE, a week of recruiter and interviewer time plus around $10,000 per hire in direct costs, then 12 weeks to full productivity without structured training (8 weeks with it), and it reports that a junior SRE can take up to a year to be ready to go on call. That is roughly 25 weeks from starting the search before an untrained hire is fully productive. Your own figures will differ, so we recommend writing your assumptions down where others can test them before you commit to a hiring plan.
Retention matters just as much, because every departure restarts that clock and a rota that wears people down is a reason they leave. To keep the load bearable, we recommend shorter shifts, split shifts, emergency swaps and case-by-case exemptions.
Why heroics are not a plan
Relying on heroics is a mark of a reactive organisation (one that responds to problems rather than preventing them), and the one engineer who always picks up is the familiar example. Their holidays become gaps in cover and their load usually runs past the limits above. The opposite habit, paging the whole team, has its own problem: the bystander effect, where everyone assumes someone else will respond. We prefer a named, trained responder for a fixed period.
The realistic options
- Shared developer rota. This suits teams whose services rarely page, who can accept a 30-minute response, and who have enough engineers to keep each person’s share within the limits above. Developers know the latest code changes, which often matters most in an incident. Clean alerts and written runbooks (step-by-step fixes for known problems) make it work.
- Follow-the-sun. If you already have engineers in two distant time zones, daylight follow-the-sun covers about 21 hours without anyone working late nights, with the six-per-site minimum above.
- Hiring SREs. This makes sense when reliability is central to the product and you can fund a team of eight or more over time, with the hiring timeline above built into the plan.
- A managed service. An outside team holds the pager. One caveat applies: even when someone else is primary, we recommend your developers keep a 24/7 escalation path, because the people who know recent changes are often needed to find the trigger. Ask what reaches your team, and how often.
How we apply this
Our SREs watch your AWS, Azure and GCP production around the clock: an engineer acknowledges every alert within 15 minutes and confirms the cause and how serious it is within 30, both written into your contract. Known issues with a runbook you’ve approved are handled by that runbook, and anything new goes to your on-call engineer with the evidence, so you still need someone reachable, but they start from the work we’ve already done. Before cover starts, a one-page service charter sets out which services we cover and how, and we run practice incidents with your engineers as part of our reliability work.