Monzo published three on-call models at three company sizes - with pay figures and honest failure notes. A teardown of the scaling cliffs every org hits.

Every On-Call Model Has an Expiry Headcount: Lessons from Monzo’s Public Record

TL;DR Scaling on-call rotation models is a function of headcount and system complexity, as demonstrated by Monzo’s three major rewrites between 50 and 150+ engineers. Organizations typically transition from a centralized "first line" to a tiered specialist model, and finally to a decentralized, team-led approach to eliminate routing latency and context gaps.

Scaling an engineering organization is a series of "cliffs" where the processes that moved you from 10 to 50 engineers suddenly become the primary bottleneck to 100. Perhaps nowhere is this more visible than in incident response. Monzo, the UK-based digital bank, provides a rare longitudinal look at this evolution, having published detailed accounts of their on-call redesigns in 2018, 2020, and 2022.

Why Monzo is the right case

For most companies, on-call is a "black box" of tribal knowledge and unstated stress. Monzo is different for two reasons. First, as a regulated bank, downtime is not just a nuisance—it’s a matter of regulatory compliance and immediate financial impact. Second, they are the only major engineering org to publish their on-call rotation models at three distinct sizes, including compensation figures, response SLAs, and a candid post-mortem on why each previous model failed.

Era one (~50 engineers, 2018): One rota to cover everything

In 2018, Monzo operated with a single, centralized "first-line" rota. At approximately 50 engineers, the model was straightforward: a small group of volunteers handled all out-of-hours alerts.

This model buys a small org coverage. It assumes that a single competent engineer can hold the mental model of the entire system. According to the 2018 Monzo blog, the goal was simple: ensure someone is always there to catch the page. At this size, the communication overhead is low enough that "the person on call" is often just one Slack message away from the person who wrote the code.

Era two (~100 engineers, 2020): Pay, shadows, and specialists

By 2020, the "one rota" model creaked. Monzo moved to a tiered structure: a Primary First Line and a Secondary "Shadow" rota (for training), supported by Specialist rotas (e.g., Platform, Payments).

They also formalized compensation. Monzo paid GBP 500/week for the primary first line and GBP 300/week for specialist rotas. This created a "waiting list" to join the rota—a rare feat in engineering. They maintained a 15-minute acknowledgment SLA, though PagerDuty data showed actual response times were often under five minutes.

However, the "tell" that this model was temporary was already in their documentation: their stated North Star was routing alerts directly to owning teams. The first line was increasingly becoming a "human router," paging the people who actually knew how to fix the problem.

Era three (150+ engineers, 2022): Delete the middleman

At 150+ engineers, the tiered model hit a "scaling cliff." The barriers to entry for the first line were rising weekly—no one could keep up with the sheer breadth of microservices. They hit a "circus factor" where expertise was concentrated in just 2-3 people, and the Platform team was consistently overloaded with alerts they didn't own.

On-call 3.0 deleted the central first-line rota entirely. Alerts now route directly to the owning teams. Engineering Managers (EMs) now own their teams' schedules and wellbeing. To maintain coordination, they introduced a Technical Incident Manager (TIM) role—a cross-org rota of seniors who don't fix the code but act as the "air traffic control" for major incidents.

The scaling cliffs, generalized

Monzo’s evolution reveals three predictable constraints that dictate how on-call rotation models must change:

~50 Engineers (Coverage is the constraint): Can we reliably wake someone up?
~100 Engineers (Context breadth is the constraint): Can the person we woke up understand the alert?
~150+ Engineers (Routing latency is the constraint): How much time are we wasting moving the alert from a generalist to the subject matter expert?

Key Takeaway: On-call models expire by headcount because the ratio between total system complexity and individual cognitive capacity eventually breaks all centralized rotas.

What decentralization quietly requires

Decentralizing on-call to 20+ different teams solves the "routing latency" problem, but it introduces a new, hidden cost: investigation capability.

In Era Two, the "Generalist" on-call had to know who to call. In Era Three, every engineer on every team needs the ability to investigate their own services at 3 am. This requires a standard of observability and automated evidence gathering that many teams lack. According to Monzo's 2022 update, this shift required their Platform team to focus on building "self-service" tools like their open-sourced Response app to lower the cognitive load on individual teams.

Common pitfalls

Copying the "End State": Early-stage startups shouldn't jump to Era Three. Without the scale, the overhead of 15 different team rotas is higher than a single central one.
The "Shadow" Trap: Many orgs use shadow rotas for training but fail to pay for them. Monzo successfully used shadows as a paid training pipeline.
Ignoring the TIM: If you decentralize without a "Technical Incident Manager" layer, major incidents involving 4+ teams become chaotic, as no one owns the "big picture" communications.

Sources & further reading

According to the Monzo 2018 post, early success relied on a high-affinity volunteer base.
The 2020 evolution post highlights the importance of paid rotas to ensure sustainability.
In the 2022 scaling post, Monzo identifies the "middleman" friction as the primary driver for decentralization.

Moving to a decentralized model like Monzo’s Era Three requires making the "investigation" phase of an incident as low-friction as possible. This is where a self-hosted platform like Operate becomes critical. When alerts route directly to owning teams, Operate provides the instant evidence and root-cause analysis that allows any engineer—not just the "hero"—to understand the incident's context before they've even finished their first cup of coffee. By automating the investigation, teams can scale their on-call responsibilities without scaling their stress.