Incident Response Guide for Small Teams

What this guide covers

Incident response is what happens between "something is wrong" and "it is fixed and we learned from it." This guide lays out a process small teams can actually run: how alerts reach a human, who owns the response, how severity shapes the reaction, how you communicate, and how you review afterward — without borrowing enterprise ceremony you do not need yet.

• One incident lead keeps decisions and communication coherent.
• Severity decides how heavy the response should be.
• A recorded timeline makes the post-incident review honest.

The four phases of an incident

Every incident moves through the same phases, whether it lasts five minutes or five hours. Naming them keeps a stressed team oriented.

• Detect — a check fails and an alert reaches a human.
• Triage — assess severity and customer impact, assign a lead.
• Mitigate — restore service, even if the root cause is not yet understood.
• Review — reconstruct the timeline and capture concrete follow-ups.

Severity levels that mean something

A simple three-level scale is enough for most small teams. SEV1: customers cannot use a core function — all hands, immediate. SEV2: degraded or partial impact — one owner, urgent but not paging everyone. SEV3: minor or internal — handled during working hours. The point of severity is to right-size the response: not every alert deserves a war room, and a real SEV1 should never wait behind triage of low-priority noise.

Roles: keep it to one lead

For a small team, the most important role is the incident lead — one person who owns coordination, decides on mitigations, and controls communication. They do not have to be the one typing fixes; they keep the response coherent so two engineers do not apply conflicting changes. For larger incidents, split out a separate communications owner who handles the status page and customer updates, freeing the lead to focus on recovery.

How Sandglass supports the practice

Route production alerts to one channel and page a single incident lead. Sandglass detects the outage with your checks, routes it to email, a Slack channel, or a webhook, and records when the incident opened and recovered — so your timeline starts from real timestamps rather than someone's memory. Publish customer updates on your status page while the lead coordinates the fix.

• Back the practices here with HTTP, ping, TCP, content, SSL certificate, and heartbeat checks.
• Route incidents to email, Slack webhook channels, and generic webhooks so the right people respond fast.
• Use a public status page to keep customers informed while the team works the incident.

Common mistakes to avoid

Incident process fails when every alert becomes a meeting. If a minor staging blip triggers the same response as a checkout outage, people learn to ignore the process. Use severity, clear ownership, and defined recovery criteria so the weight of the response matches the real customer impact.