SRE for Teams of One: Running On-Call Without a Dedicated Rotation

Most SRE advice assumes an SRE team. It assumes someone whose job title contains the word “reliability,” a rotation with enough people that nobody’s on call more than one week a month, and a budget line for incident tooling. If you’re a five-person startup where the person who wrote the payments integration is also the person who gets paged when it goes down, almost none of that advice transfers directly. The principles still apply — you just have to apply them at a scale of one or two people instead of a team of eight.

The single most useful idea from SRE: an error budget, sized honestly

The core SRE insight isn’t tooling — it’s the idea that reliability has a budget, and spending all of it perfectly is itself a mistake. A service that’s “too reliable” absorbed engineering time that could have shipped features, for a reliability improvement nobody asked for. For a small team, this cuts the other way from how it’s usually taught: the risk isn’t over-investing in reliability, it’s treating every alert as equally urgent because there’s no formal budget to say otherwise.

Set one explicitly, even informally: decide what “good enough” uptime looks like for your actual product (a B2B tool used during business hours has very different requirements than a consumer app), and stop treating every 2am blip as a five-alarm fire if it’s within that budget. Write the number down somewhere visible — even a single sentence in your README (“we target 99.5% uptime during business hours, best-effort outside them”) gives you and anyone paged at 2am permission to make a judgment call instead of treating every page as equally critical.

Google’s “two actionable incidents per shift” rule, applied to one person

Google’s SRE Workbook recommends capping actionable incidents at roughly two per on-call shift as a sustainable baseline — beyond that, response quality degrades and burnout risk climbs fast. For a team of one, this number matters more, not less, because there’s no second person to absorb an overflow week.

If you’re regularly getting paged more than twice in a shift, the fix isn’t a bigger team — it’s almost always one of three things: alert thresholds that fire on noise instead of user-impacting conditions, a recurring root cause nobody’s actually fixed because everyone’s too busy responding to it, or monitoring gaps that turn a single incident into four separate alerts. Track shift-over-shift page counts for a month before doing anything else. The pattern is usually obvious once it’s written down instead of just remembered as “a rough week.”

A rotation that works with two or three people

You don’t need four people for a sustainable rotation, but you do need more than one. A primary-plus-backup model with weekly swaps works for teams as small as two: one person is primary, one is backup, and they swap the following week. The backup isn’t idle — they’re the person who steps in if primary is unreachable, and they’re who primary hands off context to at end of shift.

The failure mode to avoid is the informal version of this: “just ping whoever’s around.” That looks fine until the week everyone’s traveling to the same conference, or the incident happens at 11pm on a Saturday and “whoever’s around” turns out to be nobody, and the page silently drops. An explicit rotation — even a shared calendar with two names on it — beats an implicit one every time, because it makes the gap visible before it becomes a missed page instead of after.

What to actually automate first

With no dedicated tooling budget, automation effort has to be spent where it returns the most. In order:

1. Escalation, not detection. If a page goes unacknowledged in 5 minutes, it needs to automatically reach the backup — this is the single highest-leverage automation for a tiny team, because a missed page with no fallback is worse than almost any other failure mode.
2. Deduplication. One underlying issue should produce one page, not six. This is less about sophisticated correlation and more about making sure your alerting rules don’t fire the same condition from three different checks.
3. Runbook links in the page itself. Not a full runbook system — a one-line link or note attached to each alert type, written by whoever’s least rushed, read by whoever’s most rushed at 2am.
4. Auto-remediation, last. Restarting a crashed pod or draining an unhealthy node is genuinely useful automation, but it’s also the easiest to get wrong without guardrails — rate-limit it, cap retry attempts, and make sure it fails loud (pages a human) rather than silently looping.

Notice what’s not on this list: a custom incident management platform, a status page generator, a full postmortem template library. Those matter more as the team grows. At two or three engineers, they’re organizational overhead disguised as tooling.

Where a monitoring platform actually helps a team this size

The honest case for paying for a monitoring platform at this stage isn’t dashboards — it’s exactly the deduplication and escalation logic above, built once by someone else instead of assembled from Alertmanager routing rules by whoever has a free afternoon. VantraOps’s health checks use debounced open and resolve states specifically so a flapping pod doesn’t generate a fresh page every time it restarts, and its AI-assisted root cause analysis does the “what changed recently” correlation work that otherwise falls on whoever’s awake at 2am with a laptop and a hunch.

None of that replaces judgment about what your error budget should be — that’s a decision only your team can make, informed by what your actual users need. It just means the on-call engineer spends less of a 2am shift on mechanical correlation work and more of it on the actual decision.

Frequently asked questions

How many people do you really need for a sustainable rotation? Two, at minimum, using a primary-plus-backup model. One person with no backup isn’t a rotation — it’s a single point of failure that happens to be a person instead of a server.

What’s a reasonable page frequency before something’s actually broken, not just annoying? Google’s benchmark of roughly two actionable incidents per shift is a reasonable target. If you’re consistently above that, look for a recurring root cause or noisy alert thresholds before assuming you need more headcount.

Should a two-person team bother with formal incident postmortems? A lightweight version, yes — even three bullet points (what happened, what we changed, what we’re watching) written within a day while memory is fresh. Skip the meeting; the value is in the writing, not the ceremony.

When does it make sense to hire a dedicated SRE instead of using tooling? Usually once on-call load is spread across enough services that no single engineer can hold the full mental model anymore — see our breakdown of hiring your first SRE vs. buying tooling for a more detailed framework.

Want to see what debounced health checks and AI-assisted root cause analysis look like in practice? Start free with one cluster — no card required.