Most on-call advice is written for organizations with a dedicated SRE team, a follow-the-sun rotation across three continents, and a dashboard nobody outside the ops team has ever opened. None of that applies when your entire engineering team is five people and everyone also writes features during the day. On-call at that scale needs different rules, or it turns into a tax that burns out whoever’s least willing to push back.
Rotate, even if it feels unnecessary
The instinct on a small team is to let whoever built a feature handle its incidents, since they know it best. This seems efficient and quietly turns into a problem: one person becomes the permanent safety net, gets paged constantly, and everyone else’s incident-response skills atrophy. Put a real rotation in place even at five people – a week each, or two if pages are rare. The person on call that week owns everything, not just their own code. This forces documentation and runbooks to exist, because the person responding won’t always be the author.
Write down what “page me” means
Vague escalation criteria are the fastest way to make on-call miserable. If every anomaly pages someone at 2 a.m., people learn to ignore pages, which defeats the point. Define a short list of conditions that justify a page – user-facing outage, data loss risk, authentication failures, error rate above a hard threshold – and route everything else to a ticket that gets triaged in the morning.
Page immediately:
- API error rate > 5% for 5+ minutes
- Any 5xx spike on checkout or login
- Database replica lag > 60s
- Background job queue depth growing unbounded
File a ticket, no page:
- Single failed job with automatic retry succeeding
- Non-critical third-party API degraded
- Elevated latency within SLAGoogle’s SRE book has a chapter specifically on what makes on-call sustainable, and the core idea holds at any team size: a page should always be actionable and should always matter (sre.google/sre-book – being on call).
Budget for the interruption, not just the response
A page at 3 a.m. doesn’t just cost the ten minutes spent fixing the issue – it costs the rest of that person’s next day, when they’re running on four hours of sleep and shouldn’t be reviewing anything sensitive. On a small team, build this into planning explicitly: whoever was on call and got paged overnight doesn’t owe a full day of output the next morning. Treating on-call as free capacity is how you lose people.
Tooling doesn’t need to be a budget line
You don’t need an enterprise incident platform to run a five-person rotation well. A free-tier alerting tool wired to your existing monitoring, a shared calendar for who’s on call this week, and a pinned doc with escalation steps covers real needs at this scale. The expensive platforms earn their price once you have dozens of services and multiple teams sharing an escalation policy – below that, the extra configuration surface is often just another thing someone has to maintain instead of ship product.
Keep a running incident log
Even lightweight incidents deserve two sentences in a shared doc: what happened, what fixed it, what would prevent it. At five people you don’t need a formal postmortem template, but you do need a record, because the same failure mode will recur in six months and nobody will remember the fix. This log becomes the seed of your runbooks – the next person on call searches it before paging anyone else.
The habit is worth more than the format. A plain markdown file in the repo, sorted by date, with a one-line summary and a link to the fix, beats an elaborate incident-management tool that nobody updates because logging an entry takes ten clicks instead of one commit.
Make handoff a real conversation
When the rotation changes hands, spend five minutes actually talking – not just a bot message saying “rotation updated.” What’s flaky right now, what’s mid-fix, what alert fired twice this week and might fire again. Atlassian’s guide to on-call health has good language for framing this as a habit rather than a formality (atlassian.com – on-call guide).
Don’t skip the retro because the team is small
It’s tempting to treat a five-minute Slack thread as sufficient after a minor incident, and sometimes it is. But anything that paged more than one person, or took more than thirty minutes to resolve, deserves a real look at why – not to assign blame, there’s nowhere to hide blame on a team this size anyway, but because the same five people will be the ones fixing it again if the root cause never gets addressed.
On-call at five people will never look like on-call at a company with a platform team. That’s fine – the goal isn’t to import a large-company process, it’s to make sure the pager doesn’t quietly become one person’s permanent problem, and that whoever’s holding it knows exactly what deserves to wake them up.