The first five minutes of an incident are rarely long enough to diagnose it. They are long enough to damage the evidence, widen the uncertainty, and create three competing versions of what happened.
That’s why my opening runbook is intentionally conservative. It doesn’t promise resolution. It establishes a usable starting state for the work that follows.
Stop adding motion
The first step is to pause unrelated changes and automatic cleanup that could alter the affected area. This isn’t a grand freeze on every system. It’s a narrow hold on actions likely to rewrite the conditions I’m trying to understand: deployments, configuration edits, manual restarts, log rotation outside its normal policy, or a script that keeps “fixing” the same symptom.
The step exists because activity feels like progress under pressure. Restarting a process can restore service, but it can also erase its transient state and reset the only counters that showed how it failed. Redeploying can replace logs, move traffic, or introduce a second variable. If recovery requires an immediate action, I’ll take it. I want that to be a conscious trade, not the reflexive opening move.
The note should name what was paused and what was allowed to continue. Otherwise “change freeze” becomes folklore and people stop useful work that has no relationship to the incident.
Write the symptom without diagnosing it
Next I record what is actually being observed. Which user-visible or operator-visible behavior is wrong? Which path produced it? What was expected instead? When was it first observed, and is it continuous or intermittent?
The wording matters. “Database issue” is already a diagnosis. “Save requests remain pending and no confirmation appears” is a symptom. The second statement keeps the investigation open to the browser, network, application, queue, database, or a dependency I haven’t considered. Early labels attract evidence that agrees with them.
I also separate the first observed time from the suspected start time. A report at one time doesn’t prove the condition began then. Logs or metrics may later establish an earlier boundary. Pretending the timestamp is exact too early narrows searches and can make relevant evidence look unrelated.
This step gives everyone one sentence to work from. It won’t stay perfect, and that’s fine. It can be revised as facts arrive, with the earlier wording retained so the investigation doesn’t quietly rewrite its own history.
Mark the evidence window
Once the symptom is stated, I capture a rough time window and the identities of the paths involved. That might include a service, scheduled job, host class, browser route, or input type. I don’t start with a complete infrastructure inventory. Five minutes can disappear while I lovingly document components that aren’t implicated.
The window guides the first preservation work. Save the relevant log slice before rotation. Capture current process and resource state if it may change. Record recent deployment or configuration identities. Preserve the exact error response or screenshot when the failure is visible at an interface. Secrets and private payloads don’t belong in the incident note; evidence can be useful without becoming a data spill.
Why preserve before searching deeply? Because search is repeatable and transient state often isn’t. I can form a better query later. I can’t ask an overwritten log what it used to contain.
The runbook should specify safe capture locations and access boundaries in advance. An incident is a terrible time to improvise a public paste, copy a credential into notes, or collect entire records when a timestamp and error class would do.
Establish one coordinator
Even a small incident benefits from one person maintaining the working account. This isn’t a command structure for its own sake. It prevents two investigators from restarting the same process, changing the same file, or presenting different symptom descriptions as current.
The coordinator records actions before or as they happen: who is checking which area, what they changed, and what observation followed. Other people can investigate in parallel, but their work needs distinct lanes. “You inspect recent changes; I preserve application evidence” is useful. “Everybody look around” mostly produces duplicate terminal history.
If I’m alone, I still name the role in my notes. It reminds me to keep a timeline while the investigator in me wants to open six shells. Those six shells are very persuasive and have poor handwriting.
Choose the next reversible question
At the end of the opening sequence, I choose one question that can reduce uncertainty without destroying much evidence. Did the affected request reach the application? Does the application log show completion? Is the expected configuration loaded? Can a read-only check distinguish a routing problem from a processing problem?
The best next action isn’t necessarily the most likely fix. It’s the observation that divides the search space cleanly and can be repeated. If a mutation is necessary to restore an important function, the note should state the expected benefit, the evidence it may erase, and what would trigger reversal. Urgency doesn’t cancel tradeoffs. It compresses the time available to name them.
Five minutes is a guideline, not a stopwatch ritual. A severe condition may require immediate protective action. A small failure may allow a slower start. The runbook’s job is to keep the first response from becoming a pile of irreversible guesses.
By the time this opening is complete, I may not know the cause. I should know what is wrong, roughly when it was observed, which evidence has been protected, who is coordinating, and which question comes next. That’s enough to begin the incident without making the second five minutes about recovering from the first.