Alert Escalation for Solo Developers and Small Teams

"Escalation" sounds like an enterprise word. It conjures up on-call rotations, incident commanders, PagerDuty dashboards, a room full of ops engineers. So solo developers and small teams tend to assume it isn't for them — that escalation is something you adopt later, once you're big enough to have a "team" worth the name.

That's backwards. A solo developer is the person who needs escalation most, because there is no one else. On a big team, if one engineer sleeps through an alert, another might catch it. When you're on your own, a missed alert is just a missed alert — the outage runs until you happen to notice. Escalation is the mechanism that substitutes for the second person you don't have.

This guide is about building that mechanism at a realistic scale: what escalation actually is, why it matters more when you're small, and how to set up an alert chain that reliably reaches a human — without buying software designed for a 200-person engineering org.

Alert vs escalation: the distinction that matters

An alert is a single event: one email, one SMS, one Slack message. It fires once and it's done. Whether a human actually saw it is not the alert's problem.

Escalation is a sequence with a feedback condition. It works like this: fire the first alert, then wait. If nobody acknowledges within a set time, fire a second alert — louder, different channel. Wait again. Still nothing? Fire the third. Keep going until a human explicitly acknowledges — clicks a link, replies to the SMS, presses a key on the call — at which point the chain stops.

The key word is acknowledges. A plain alert is satisfied when it has been sent. An escalation chain is satisfied only when a human has responded. That difference — sent versus responded — is the entire reason escalation exists, and it's why a single alert, however well configured, has a hole in it.

Why being small makes this more urgent, not less

There are a few reasons escalation matters more for a one-person or small operation:

• No redundancy of humans. A big team has implicit backup — many people see the same channel. You don't. The chain has to be your backup.
• No dedicated ops. Nobody is paid to watch dashboards. The monitoring has to come find you, because you are not going to go looking.
• You're often away from the keyboard. Solo and small means you're also doing sales, support, sleep. Alerts have to reach you off-screen — on a phone, as something that rings.
• The cost of a long outage is concentrated. When you're small, a six-hour silent outage can mean a meaningful chunk of revenue or your reputation with an early customer. There's less margin to absorb it.

None of this requires a big-company solution. It requires a correctly shaped small one.

What a small-scale escalation chain looks like

You don't need a complex routing tree. For a solo developer, a good chain has three or four steps, ordered from quiet-and-cheap to loud-and-certain.

For a solo developer

1. Step 1 — email + Slack/Discord. Instant, free, creates a written record. If you happen to be at your desk, this is all you'll ever need. Wait ~2 minutes for an acknowledgment.
2. Step 2 — SMS. No acknowledgment? Send a text. It reaches your phone even when you're away from the screen.
3. Step 3 — voice call. Still nothing after a few minutes? The system calls your phone. This is the step built to physically wake you. (See the companion guide on getting a phone call when your site goes down.)
4. Step 4 — a second person. This is the step solo developers skip, and shouldn't. Pick one trusted contact — a co-founder, a technical friend, a freelancer on retainer — and make them the final step. Not because they'll fix it, but so that an outage can't run for eight hours simply because your phone was off or dead.

Step 4 is the honest answer to "but I'm only one person." You don't need a rotation. You need exactly one fallback human, so the chain doesn't dead-end at you.

For a small team

Once two or three people share responsibility, the change is to add a real on-call rotation: the chain routes to whoever is on duty this week, not always the same name. The principle is identical — quiet to loud, acknowledge to stop — but the "who" rotates so no single person carries every night. The handful of steps still look the same: notify on-call, escalate louder, voice call, then fall back to a second team member if the on-call person is unreachable.

You probably don't need PagerDuty (yet)

When a small team decides to "take alerting seriously," the reflex is to reach for PagerDuty or Opsgenie. These are excellent products — but they are incident-management platforms built for organisations with many engineers, complex routing, and dedicated ops practices. For a solo developer or a team of three, adopting one usually means paying for — and configuring, and maintaining — far more capability than you'll use.

There's also a structural cost: PagerDuty doesn't monitor anything. It's the escalation layer only. So you end up running two products — a monitoring tool to detect the outage, and PagerDuty to escalate it — wired together, two bills, two configurations.

For most small operations, the simpler and cheaper answer is a monitoring tool that has escalation built in: one product that both detects the problem and runs the alert chain. You configure the monitors and the escalation in the same place, and there's nothing to integrate. You can always graduate to a dedicated incident-management platform later, when team size and complexity actually justify it. Most small teams never need to.

Five rules for getting escalation right when you're small

1. Always have a final fallback that isn't you. One other human at the end of the chain. This is the single most important rule, and the one solo developers most often skip.
2. Order steps quiet to loud. Don't lead with a phone call — you'll get call fatigue and start ignoring it. Lead with email, save the call for when it's genuinely unanswered.
3. Acknowledgment must stop the chain. If acknowledging an alert doesn't halt escalation, you'll get called after you're already fixing the problem, and you'll learn to dread the tool.
4. Tune the wait intervals. Too short and a brief blip escalates to a 3 a.m. call needlessly. Too long and a real outage runs unattended. A couple of minutes between early steps is a reasonable starting point.
5. Test the whole chain. Trigger a real alert and deliberately ignore it. Confirm it climbs all the way to the fallback. An escalation chain you've never tested is a guess, not a safeguard.

The short version

Escalation is not an enterprise luxury — it's most needed by the people with the fewest humans to catch a missed alert. A solo developer or small team doesn't need PagerDuty; they need a correctly shaped alert chain: a few steps ordered quiet to loud, each waiting for acknowledgment before the next fires, and — crucially — a final fallback to someone other than yourself. Build that, test it by ignoring a real alert on purpose, and an outage can no longer run silently just because one phone was off.