Alert Escalation and On-Call Basics for Small Teams.

Big companies have dedicated on-call teams. Small teams have three people and a group chat - and the risk that everyone assumes someone else saw the alert. A lightweight escalation policy makes sure every critical alert has an owner without turning anyone's life into a pager.

Key takeaways

• Every critical alert goes to one named person first, not to "everyone".
• If that person doesn't respond within a few minutes, the alert escalates to a second.
• Rotate on-call weekly and hand over explicitly.
• Keep non-critical alerts out of the escalation path.
• After every real incident, ask whether the alert reached the right person fast enough.

Why "send it to everyone" fails

When an alert reaches five people at once, each one assumes another will handle it - the bystander effect. At night it's worse: everyone's phone rings, and nobody is sure who is working on it. A clear first responder removes the ambiguity.

A simple escalation policy

1. Level 1 (0 minutes): the on-call person gets SMS and a Telegram/Bale message.
2. Level 2 (after 10 minutes without acknowledgement): the backup person is alerted the same way.
3. Level 3 (after 20 minutes): the team lead or owner is alerted.

The team group receives every alert for visibility, but only the current responder is expected to act.

Setting up the rotation

• Length: one week is common - long enough to settle in, short enough to avoid burnout.
• Size: with three people, each is on call one week in three, plus backup one week in three.
• Handover: at a fixed time, the outgoing person passes on open issues, recent incidents and anything flaky.
• Calendar: keep the rota somewhere everyone can see, and update alert contacts when it changes.

Protecting the on-call person

• Only critical monitors page outside working hours; warnings wait until morning.
• Fix the top sources of noise first - see cutting false alarms.
• Give time off after a bad night.
• Write short runbooks for frequent alerts: what to check, how to restart, who to call.

What the responder does

1. Acknowledge - let the team know you are on it.
2. Assess impact - which users and features are affected? Check the monitor's locations and errors.
3. Communicate - post a first update on the status page if users are affected.
4. Mitigate first - restart, roll back, fail over. Root-cause analysis comes later.
5. Hand over or close - if it drags on, bring in help; when resolved, post the recovery.

Learn from each incident

After significant incidents, spend 30 minutes on a blameless review:

• How did we find out - monitor, customer, or by accident?
• Did the alert reach the right person, and how long did it take to respond?
• What would have detected it earlier?
• What one change prevents a repeat?

Track mean time to detect (MTTD) and mean time to recover (MTTR). If detection is slow, add or tighten monitors; if recovery is slow, improve runbooks and tooling.

Frequently asked questions

• Do we need on-call if our customers only work business hours?

  +

  You still need someone responsible during business hours. Out-of-hours on-call becomes necessary when outages at night or on weekends cost you money or trust.

• How many alerts per on-call week is too many?

  +

  If the on-call person is woken more than once or twice a week, the alerts need fixing. Most nights should be quiet.

• Should developers be on call?

  +

  It works well when the people who build a service also run it - they know where to look. Pair new team members with experienced ones for their first rotations.