Monzo's On-Call Rotation Models Broke Twice as It Grew

An on-call rotation is the schedule that decides who answers an out-of-hours alert, and how that person gets help. It is easy to build one in a hurry and then leave it alone while the team grows around it.

Monzo, the UK bank, is a useful case because it wrote down three versions of its rotation as it grew, in 2018, 2020 and 2022. We read all three to see what changed, why, and what each change quietly asked of the engineers on the receiving end.

In this post we cover the three eras in Monzo's own words, the headcount cliffs we think they reveal, what decentralised on-call demands from every team, when decentralising is the wrong move and how to plan the next change before the current model fails.

Why Monzo Is a Useful Case for On-Call Rotation Design

Published accounts of on-call design with real numbers are not common. Monzo published three over three years, each stating the model, the pay where it applied, and in the later posts the reason the earlier model stopped working.

That lets us compare designs at different sizes using one company's primary sources rather than a composite of anecdotes. It also lets us avoid a common mistake, which is copying the latest model without the headcount that made it necessary.

We use the three posts as our only source for Monzo's practice. Where we generalise beyond them, we say so, because the pattern may not hold for a team with a very different system or risk profile.

Era One Was a Single Volunteer Rota for About Fifty Engineers

The 2018 post describes a single rotating team. Each week three engineers were on duty, one primary, one shadow and one covering office hours only, with the rotation changing on Fridays. Engineers opted in, because "We ask engineers to opt-in to on-call" given how disruptive it is, and Monzo paid them £500 a week.

The setup was deliberately simple. Prometheus held the metrics, Alertmanager routed alerts and PagerDuty paged the person on duty. Alerts had two severities, with warnings expected to be handled within eight hours and critical alerts needing immediate attention.

A weekly handover document kept the next person informed. It recorded what had happened, what actions were taken and what had been deferred, which is the cheapest form of shared context a small team can build.

The 2022 post later described this process as the original one "for our team of 50". At that size we would expect the person on call to be a message away from whoever wrote the code, so a single rota works because everyone roughly knows everything.

Era Two Added Paid Shadows and Specialist Rotas

By May 2020 the structure had changed. The first line still held a primary and a shadow on-caller, with eight volunteers staffing each, and a set of specialist rotas sat behind it. The post explained the reason plainly, since "It's been challenging for our primary on-callers to have context on every single aspect of our system".

The first line acted as a router. In the post's words, "The main job of the engineers staffing this rota is to help find the right team to redirect the issue." Specialist rotas covered areas such as payments and were staffed by the members of the team that owned the area.

Pay and response expectations were formalised. Primary and shadow on-callers received £500 per week, specialists £300 per week, the first line had to acknowledge a page within 15 minutes and specialists within an hour. The rotas became so popular that "we've ended up with a waiting list for engineers who want to join".

The post also named the next step. Its stated goal was that almost everything should route directly to the team that owns the system, which tells us the authors already regarded the first line as a stage rather than a destination.

Era Three Removed the First Line at 150 Engineers

The February 2022 post says the original process "doesn't scale when we're now a team of 150+ engineers", and it explains why in three parts.

• The primary rota "was often a point of friction between an alert firing and it being addressed by the team who had the right context and knowledge to quickly fix it".
• The platform team, acting as primary during office hours, suffered "undue stress", and Monzo was "heading towards a position where we had two or three individuals in the organisation who were critical to on-call functioning properly".
• The barrier to joining the primary rota "was so high that it started to put people off", which made staffing it expensive and slow.

The replacement routes "alerts directly to owning teams who are each on-call for the systems they own and run". A group of engineering leaders trained for major incidents, called Technical Incident Managers, supports responders around the clock. Engineering managers became responsible for making sure their teams' schedules are well staffed and their engineers supported.

Unlike the earlier posts, this one does not give a pay figure, so we make no claim about compensation in the current model.

Three Headcount Cliffs Every On-Call Rotation Meets

Read together, the posts show one constraint giving way to the next as the organisation grows. The framing below is ours, built on Monzo's account rather than stated by Monzo, and the headcount bands are the ones the posts give or imply.

Era	Stated size	Model	Constraint that broke it
2018	A team of 50	One opt-in rota with primary, shadow and office-hours cover	Context breadth, because one person had to understand every service
2020	Not stated	Paid primary and shadow first line plus specialist rotas	Routing latency, because the first line mostly redirected pages
2022	150+ engineers	Alerts routed to owning teams with incident managers	Investigation capability, because every team must diagnose its own systems

The pattern matters more than the exact numbers. We would expect the cliffs to arrive at different headcounts for a system with fewer services or a stricter service-level agreement, so the useful question is which constraint your current model is closest to breaking.

1. Coverage Comes First

At the smallest size the only question is whether someone reliably wakes up. A volunteer rota, a handover document and a pager answer it, and the cost of not knowing who owns what is low because there are few owners.

We would not add structure here. A tiered model with specialists solves problems this team does not have yet, and its coordination costs would exceed its benefits.

2. Context Breadth Comes Second

As the system grows, the person woken up can no longer understand the alert. Monzo's answer was to add a router and domain specialists behind it, which bought time and kept rotas attractive enough to build a waiting list.

The price was a hop. Every page that belongs to someone else crosses a first line before it reaches them, and the first line carries the stress of being responsible for everything it does not understand.

3. Routing Latency Comes Third

Once most pages are redirected, the redirect itself is the delay. Monzo's 2022 post describes exactly this friction between an alert firing and the team with context addressing it.

Removing the middleman fixes latency and the concentration risk of two or three critical people. It also moves a duty onto every owning team, which is the subject of the next section.

What Decentralised On-Call Quietly Requires of Every Team

In the second era the generalist on call needed to know who to call. In the third, each owning team needs to be able to investigate its own services at any hour, with whatever evidence the alert and its dashboards provide.

We think this is the hidden cost of the model. The posts describe routing and role changes, and the investigation skill has to exist on every rota, including for the engineer who joined last month and is on call for the first time.

Our own work on that problem is in our guides to time to first page for new on-call engineers and to incident command for software teams, which looks at the coordination role that Monzo's incident managers play.

Teams moving to owner-based routing also need evidence to be easy to gather, so an unfamiliar engineer can see what changed and what the logs say. That is the gap an AI agent that investigates with evidence is meant to narrow, by assembling logs, databases and code context for the person who was just paged.

When Decentralising On-Call Is the Wrong Move

Copying the end state is the most common error. A small team with a single rota should not split into per-team rotas, because the overhead of many small rotas is larger than the benefit when there are few services and few people who know them.

Monzo's own sequence supports the caution. Its first line and specialist rotas were a deliberate stage that ran for about two years, and the 2020 post describes them as popular with engineers, not as a mistake to be corrected.

A second caution is the missing coordination layer. If every team owns its alerts but nobody owns the cross-team picture during a major incident, communication fragments, which is the problem Monzo's incident managers address. We would add that role before decentralising rather than after the first bad night.

Finally, ownership routing only works if ownership data is accurate. If the catalogue says a service belongs to a team that dissolved, pages go nowhere, and we would fix the data first.

Plan the Next On-Call Rotation Change Before the Cliff

Ask which of the three constraints your current rotation is closest to breaking, and watch the signals that precede it, such as pages that are mostly redirected, a short list of people everyone relies on, a rising barrier to joining the rota or an alert load that our guide to on-call alert fatigue shows how to triage.

We would change the on-call rotation one constraint ahead of the failure, not after it, because a tiered model is easier to introduce while volunteers are willing than after burnout has set in. Operate brings evidence from logs, databases and code together through read-only adapters, and a separate agent on a different model checks each proposed root cause against that evidence.