An incident note tells everyone at once what is broken, what they should do in the meantime, and when the next update is coming. It is a broadcast rather than a request for a decision, which is what separates it from an escalation. The commit to a next update time is the load-bearing part: without it people ask, and answering the same question eight times is what actually slows the fix.
When to use it
Use it when something is broken that affects customers or blocks the team: the storefront down, payments failing, a shipping integration stopped, a supplier failure with immediate consequences.
The interruption is worth it precisely because it prevents a larger one. Eight people each asking what is going on is more disruptive to whoever is fixing it than one message to everybody.
The template
Post it once, then update the same message or thread rather than starting new ones, so there is a single place to look.
INCIDENT Status: [investigating / identified / monitoring / resolved] Started: [time] This update: [time] WHAT IS HAPPENING One or two sentences, in plain language. No speculation about cause while status is 'investigating'. WHO IS AFFECTED Customers: [which ones, doing what] Team: [who is blocked, from doing what] WHAT TO DO MEANWHILE [role]: [do this] [role]: [do not do this] Customer line: "[the exact wording to send]" WHO IS ON IT [name] - fixing [name] - handling customers Nobody else needs to do anything. NEXT UPDATE [time] - whether or not there is news.
How to adapt it
- Keep "whether or not there is news". Silence is read as nothing being done, and it is the reason people start asking.
- Give the exact customer wording. Without it, five people improvise five different answers and you inherit the inconsistency.
- Name who is not needed. "Nobody else needs to do anything" prevents four people investigating the same thing in parallel.
- Do not speculate on cause early. An early wrong theory gets repeated to customers and outlives the correction.
Why it is this short
Long incident updates do not get written during an incident, and the person best placed to write one is usually the person fixing the problem.
The structure exists so it can be filled in badly and still work. Even a half-completed version answers the questions that would otherwise arrive as interruptions.
Common questions
What should an incident note contain?
What is happening in plain language, who is affected, what people should do meanwhile including exact customer wording, who is handling it, and when the next update comes.
How often should I update during an incident?
At the interval you committed to, whether or not there is news. An update saying nothing has changed is what stops people asking.
How is this different from an escalation?
An escalation asks a specific person for a decision. An incident note tells everyone at once what is happening so they stop asking and know what to do meanwhile.