Incident Response Basics
When something breaks, a calm process beats heroics. Detect, declare, communicate, and resolve — then learn.
What you'll learn
- Describe the lifecycle of an incident from detection to recovery
- Assign clear roles so response is coordinated
- Prioritise restoring service over diagnosis
- Communicate status to the people who depend on you
7 min
What counts as an incident
An incident is an unplanned disruption that affects, or threatens to affect, your users — an outage, severe slowness, or a data problem. Naming something an incident is not an admission of failure; it is what activates a coordinated response. Declaring early, even if you are not yet certain how bad it is, beats hesitating while the impact grows.
Agree in advance what severity levels mean, so "is this an incident?" is not debated mid-crisis. A simple scale — from minor degradation to major outage — lets everyone calibrate the response to the impact without lengthy argument when minutes matter most.
Roles keep response calm
Unstructured response is chaotic: everyone investigates at once, nobody communicates, and effort is duplicated. Assigning roles fixes this. An incident commander coordinates and decides, freeing others to focus on their parts. A communications role keeps stakeholders informed. Responders investigate and fix. The commander's job is to lead, not necessarily to be the deepest technical expert.
For a small team these roles may be one or two people wearing several hats, and that is fine — the point is that someone is explicitly holding each responsibility. Clear ownership turns a frantic scramble into an organised, calmer effort even under real pressure.
Restore first, diagnose later
During an incident, the priority is to stop the bleeding — restore service to users — not to find the perfect root cause. A rollback, a feature toggle, or a failover that gets users working again is the right first move, even if you do not yet fully understand why things broke. Root-cause analysis is essential, but it belongs after recovery.
Resist the temptation to keep digging while users suffer. Note what you observe for later, then take the fastest safe action that restores service. The detailed investigation happens in the calm of a postmortem, once the immediate impact is over.
Communicate clearly
People affected by an incident need to know you are aware and working on it. Honest, regular updates — even "still investigating, next update in 30 minutes" — reduce anxiety and a flood of duplicate reports far more than silence. Say what you know, avoid speculation, and keep a steady cadence so stakeholders are not left guessing.
A public status page is the natural channel for this, giving everyone a single authoritative source instead of scattered messages. Good communication does not fix the technical problem, but it preserves trust while you do.
Key takeaways
- Declare incidents early using agreed severity levels
- Assign clear roles so response is coordinated, not chaotic
- Restore service first; leave root-cause analysis for after
- Communicate honestly and on a steady cadence
- Use a status page as the single source of truth
FAQ
Should I find the root cause before fixing an incident?
No. Restore service first with the fastest safe action — a rollback or toggle — then investigate root cause afterwards. Users care that it works again; the detailed analysis belongs in the postmortem.
Do small teams really need defined incident roles?
Yes, even if one person wears several hats. The value is that each responsibility — coordinating, communicating, fixing — is explicitly owned, which prevents the duplicated effort and silence that make small-team incidents worse.
How often should I post incident updates?
On a predictable cadence, even when there is little new to report. A regular 'still working on it, next update soon' reduces anxiety and duplicate reports far more effectively than going quiet until it is fixed.
Ready to build?
Read the API reference, grab the OpenAPI spec, and ship a resilient integration.