Production Bug or Incident? A Simple Severity Triage for Small Teams
- Author
- Vishal Maurya
- Published on
- Reading time
- 4 min read
Overview
A user reports a problem in production. Is it a normal bug for the backlog, or does someone need to stop what they are doing right now? Small teams without a dedicated on-call rotation often decide this ad hoc, which leads to either panic over minor issues or slow responses to serious ones.
A simple severity scheme, agreed in advance, removes the guesswork.
1. Define Severity by User Impact
Base levels on what users and the business experience, not on how interesting the bug is technically. Keep it to three or four levels:
SEV1 Critical: core function down or data at risk for many users
(cannot log in, cannot pay, data loss or exposure, whole site down)
SEV2 Major: important feature broken or badly degraded, workaround is hard
or a significant group is affected
SEV3 Minor: limited impact, a workaround exists, few users affected
SEV4 Low: cosmetic or edge case, no meaningful impact
Adjust the examples to your product. The test is the same: how many users, how important is the function, is there a workaround, and is data or money at risk?
2. Ask a Short Set of Triage Questions
When a report arrives, answer these in a few minutes:
1. What is broken, and for whom (all users, one customer, one region)?
2. Is it still happening, or did it stop?
3. Is data being lost, corrupted, or exposed? Is money or security involved?
4. Is there a workaround?
5. Did something change recently (deploy, config, dependency, provider outage)?
Any security or data-exposure concern should be treated as high severity until proven otherwise and escalated through your security process.
3. Decide Who Decides
Ambiguity about authority wastes the first critical minutes. Name a role, not a person: the on-call engineer or the first responder can declare an incident and set the initial severity. Anyone can ask for escalation. Severity can be raised or lowered later as facts change, and over-declaring is better than under-declaring early on.
For incidents, assign roles even in a team of three: one person leads and decides, one investigates and fixes, one communicates.
4. Know When to Page
Paging interrupts people, so tie it to severity:
SEV1: page immediately, any time of day
SEV2: page during business hours; after hours only if impact is growing
or the team has agreed on it
SEV3: ticket, handle in normal working hours
SEV4: backlog
Write down who is reachable and how, even if it is only a shared phone number or a chat channel with notifications on. If nobody is on call by design, be honest about the response time customers can expect.
5. Use a Short Comms Template
Updates should be predictable and factual. Post to a status page, a shared channel, or an email list:
[SEV2] Short title - Investigating / Identified / Monitoring / Resolved
Impact: who is affected and what they cannot do
Start time: when it began (include timezone)
Current status: what we know and what we are doing
Workaround: if any
Next update: by HH:MM
Do not speculate about causes or promise fix times you cannot guarantee. Commit to the time of the next update and meet it, even if the update is "no change."
6. Mitigate First, Then Diagnose
For SEV1 and SEV2, the goal is restoring service. Roll back a recent change, disable a feature flag, scale a resource, or fail over before digging into root cause. Keep a running timeline in the channel so the write-up is easy.
7. Review and Tune
After any SEV1 or SEV2, hold a short blameless review and capture action items. Review your severity levels every so often: if everything is SEV2, the scale is miscalibrated, and if real problems are being labeled SEV3, tighten the definitions. Small teams benefit from reviewing a few real tickets against the scheme to keep everyone aligned.
Conclusion
A severity scheme does not need to be elaborate. Define levels by user impact, ask the same triage questions every time, give someone clear authority, tie paging to severity, and communicate with a consistent template.
If you want help drafting an incident process or on-call setup for a small team, I can help. Contact me.