What counts as an incident, and why to declare early
The cheapest mistake in incident response is declaring something that turns out to be nothing. The expensive one is the silent hour where everyone assumed someone else had it. Learn what actually warrants an incident and why the bias should always be toward declaring sooner.
There is a particular kind of silence that precedes most bad outages. An engineer notices something off — a graph bending the wrong way, a customer email that doesn't add up, a deploy that "probably" caused that error spike. They poke at it alone for a while. They don't want to look alarmist. They tell themselves it's probably fine, probably self-healing, probably not worth pulling anyone in over. And for the twenty or forty minutes that silence lasts, the one thing that is not happening is a coordinated response. That gap — between the moment a problem becomes knowable and the moment a team actually starts working it — is where most of the avoidable damage in an outage accumulates.
The entire purpose of declaring an incident is to end that silence on purpose. Declaring is not an admission that things are catastrophic; it is a lightweight act that converts a private worry into a shared, visible, coordinated effort. It says: this is real enough that we should work it as a team, with a clear owner and a clear record, rather than as a handful of people each quietly hoping it resolves itself.
An incident is a disruption that warrants a coordinated response
The most useful working definition is also the simplest: an incident is any unplanned disruption to your service that warrants a coordinated response. That definition is deliberately broad, and the breadth is the point. It does not hinge on customer count, on revenue, or on whether the cause is understood — all of which are unknown in the first minutes, exactly when you need to decide. It hinges on a single judgment a responder can actually make in the moment: does this deserve more than one person, working in the open, right now?
Notice what this definition excludes. A planned maintenance window is not an incident — it is expected, communicated, and coordinated in advance. A single transient error that recovered on its own before anyone looked is not an incident, though a pattern of them might be. A feature request, however urgent, is not an incident. The line is unplanned disruption plus the need for coordination; routine work, planned work, and one-off blips that self-heal sit on the other side of it.
What this definition crucially does not require is certainty about impact. "Users are reporting checkout failures" is an incident even before you know how many users, even before you know it's really checkout and not the payment provider, even before you know if it's one region or all of them. You declare on the signal that something is wrong and warrants coordination, and you refine your understanding of the impact afterward — that is what the response is for.
Declaring early is cheap; declaring late is not
The asymmetry here is everything, and it is worth making explicit because human instinct gets it backward. Declaring an incident that turns out to be minor costs you almost nothing: a few minutes of a couple of people's attention, a record that gets resolved quickly, maybe a mildly anticlimactic "all good, it was a flapping health check." That is the entire downside. Nobody's career has ever been damaged by a false alarm that was stood down gracefully ten minutes later.
Declaring late costs you the most valuable minutes you have. Every minute the response stays informal is a minute without a clear owner, without a shared timeline, without anyone explicitly responsible for keeping stakeholders informed. It is a minute where two engineers might be unknowingly working the same dead end, or where nobody is, because each assumed the other was on it. The damage of a late declaration is not linear — a problem that festers unwatched tends to spread, correlate, and compound, so the gap you save by declaring at minute three is worth far more than the same gap saved at minute thirty.
Because the costs are this lopsided, the correct organizational bias is unambiguous: declare early, and make standing down cheap and blameless. A team that treats a false alarm as a failure will train its engineers into exactly the silence this section opened with. A team that treats a quickly-resolved false-alarm incident as a normal, healthy thing — proof the muscle works — gets engineers who reach for the declare button on instinct, which is precisely the reflex you want at 3am.
Lower the activation energy
If declaring is a heavyweight ritual — a long form, an approval, a sense that you'd better be sure — people will avoid it, and they will avoid it most exactly when the stakes feel highest and the picture is murkiest. So the act of declaring must be near-frictionless. Anyone who can see the problem should be able to start an incident in seconds, with nothing more required up front than a short title and a first guess at how bad it is. Everything else — the precise impact, the affected components, the root cause — is something the response discovers and records as it goes, not a gate you must clear before you're allowed to begin.
A good declaration captures just enough to orient the people who are about to join: a human-readable summary of the symptom ("checkout returning 500s for EU users"), an initial severity that says how hard to push, and ideally a pointer to where the conversation is happening. It does not demand a diagnosis. Writing "cause unknown" in the first minute is not a failure of the process; it is the process working as intended, because the response that follows is the machine for turning "cause unknown" into "cause fixed."
When in doubt, declare
Most of the judgment around incidents can be compressed into a single heuristic that holds up remarkably well under pressure: when you are not sure whether something is an incident, it is. The very fact that you are uncertain enough to ask the question means the situation is ambiguous, unfolding, and probably benefits from more than one set of eyes — which is the definition. The downside of declaring and being wrong is a few minutes and a shrug; the downside of not declaring and being wrong is the silent hour. Bias every close call toward the cheap mistake.
Encode that bias into how your team operates. Make declaring a one-step action any responder can take without permission. Celebrate the fast stand-down as loudly as the fast fix — both are the system working. And measure the thing that actually matters: not how few incidents you declare, but how short the gap is between when a problem became knowable and when a coordinated response began. Close that gap and almost everything else about incident response gets easier, because every other part of the discipline — assessing severity, assigning roles, communicating, learning — can only begin once someone has been brave enough, and unburdened enough, to say the words out loud: this is an incident, and we are on it.