lecode

Escalation policies for teams of one (and teams of five)

September 8, 2026 · admin@lecode.tech

Most incident response documentation is written for a team that doesn't exist yet — twenty engineers, a dedicated SRE function, a status page with a communications lead. If you're a team of one, or five, that document is useless the moment you open it. What you actually need fits on an index card: who gets paged first, who gets paged if they don't respond, and how long to wait before escalating.

Three rules beat forty pages

Rule one: every alert has exactly one owner at any given moment, never a group. "The backend team" doesn't respond to a page — a specific person does, and if the rotation doesn't say who, everyone assumes someone else has it. Rule two: escalation has a fixed timeout, not a judgment call. Five or ten minutes with no acknowledgment, and it moves to the next person automatically. Rule three: acknowledgment is cheap and visible — a tap, not a Slack essay — so the rest of the team can see the alert is handled without pinging to ask.

That's the whole policy. It works identically whether there's one person on the rotation or five, because none of the three rules assume a specific team size — they just assume someone, eventually, needs to know if a page went unanswered.

Solo on-call is still on-call

If you're the only person who can respond, escalation still matters — not to hand off to someone else, but so a second channel exists in case the first one fails silently. A push notification that gets buried under twelve others is functionally the same as no notification at all. The fix isn't a bigger team, it's a louder second attempt.

Built into Blare, not bolted on

This is why escalation policies and on-call schedules are core to Blare rather than a paid add-on: a solo developer and a five-person on-call rotation are running the exact same three rules, just with a shorter or longer list of names. Invite your rotation, set the timeout, and know at a glance who's responsible for what right now — not who's theoretically on the schedule this week.

on-callincident-responsedevops