How to Write an Incident Situation Report
An incident situation report, or sitrep, is a short, regular status update during an incident. It states what is happening, who and what is affected, current severity, actions taken and in progress, known unknowns, the next steps, and when the next update will come. Sitreps keep stakeholders informed without interrupting responders and create a record of how the incident evolved.
What a sitrep is for
During incidents, stakeholders such as leaders, support, sales, and partner teams need to know what is happening. Without structured updates, they ask responders directly, which slows the fix. Sitreps give everyone the same information on a predictable schedule.
What to include
Every sitrep should cover the same six things, in the same order, so readers know where to look.
Summary
One or two sentences describing the problem in plain language.
Impact
Which services, customers, regions, or functions are affected, and how severely.
Status and severity
Current state, such as investigating, mitigating, or monitoring, and severity level.
Actions
What has been done and what is in progress.
Unknowns
What is not yet known, stated explicitly.
Next update
When the next sitrep will be sent, even if nothing changes.
Cadence
Set update frequency by severity: for major incidents, often every 30 to 60 minutes; for lower severities, every few hours or at milestones. Always state the next update time and keep to it. A missed update causes more interruptions than a late one with no news.
Who writes it
The communications lead or incident lead should write sitreps, drawing on responders' notes, so engineers stay focused on fixing the problem. In smaller teams, the incident lead often does both coordination and communication.
Audience and tone
Write for readers who do not know the system. Avoid jargon, acronyms, and speculation. Be calm and factual. Do not minimise impact or promise resolution times you cannot support. Separate internal sitreps from customer-facing updates, which need more careful wording.
Facts versus hypotheses
Clearly distinguish what is confirmed from what is suspected. Saying the team suspects a database issue and is verifying is better than stating a cause that later proves wrong and must be retracted.
Where to send it
Post sitreps in a consistent place: an incident channel, an email list, the incident record, or all three. Stakeholders should know where to look without asking. Keep them in the incident record so the history is complete.
A simple template
Incident title and severity. Time of update. Summary. Impact. Current status. Actions completed. Actions in progress. Unknowns. Next update at. Contact for questions. Keep each section to a few lines.
Sitreps for security incidents
Security incidents need tighter distribution and careful wording, because details may be sensitive or subject to legal privilege. Involve legal and security leads in deciding who receives sitreps and what they contain.
After the incident
The sequence of sitreps forms a clear timeline of what was known when and what was done. Use it as a starting point for the postmortem timeline, adding precise timestamps from logs and alerts.
Where to Write an Incident Situation Report work goes wrong
Irregular updates, technical detail that stakeholders cannot interpret, speculation presented as fact, missing next-update times, and updates scattered across channels. Each increases interruptions and confusion.
Practising sitreps
Include sitrep writing in incident drills. Writing a clear update under time pressure is a skill; practice makes real incidents calmer and more consistent.
Example sitrep
Severity 1, 14:30 UTC. Checkout is failing for about a third of customers in Europe. Cause under investigation; a database failover at 14:05 is the leading hypothesis. We have paused deployments and are failing back to the primary. Unknown: whether orders placed during the window need reprocessing. Next update 15:00 UTC.
Tools that help
Incident tools with update templates, reminders when the next update is due, and audiences per severity reduce the effort of writing sitreps and make cadence reliable. Keeping updates in the incident record also means the postmortem timeline is already half written.
Customer-facing updates
Customer updates draw on internal sitreps but need simpler language, careful claims, and approval for major incidents. Avoid internal names, unconfirmed causes, and precise timelines you may miss. Acknowledge impact, describe what is being done, and give the next update time. Consistency between internal and external messages prevents confusion for account teams.
Closing sitrep
When the incident is resolved, send a final sitrep: what happened in brief, when service recovered, any remaining follow-up, and when the postmortem will be shared.
to Write an Incident Situation Report in brief
Short, regular, factual updates with a next-update time keep stakeholders informed, reduce interruptions, and let responders stay focused on the fix.
Translating technical updates
Responders speak in components and metrics. Sitreps translate that into service impact: not error rate on payments-api is elevated, but some customers cannot complete checkout.
Frequently asked questions
- What is a sitrep in incident management?
- A sitrep, or situation report, is a concise status update sent at regular intervals during an incident. It covers what is happening, impact, current status, actions taken and in progress, unknowns, and when the next update will arrive, so stakeholders stay informed without interrupting responders.
- How often should incident updates be sent?
- Set cadence by severity. Major incidents commonly get updates every 30 to 60 minutes; lower-severity incidents every few hours or at milestones. Always state when the next update will come and keep to it, even if there is no new information.
- Who should write incident status updates?
- A designated communications lead or the incident lead, rather than the engineers actively fixing the problem. Separating communication from technical work keeps responders focused and makes updates more consistent, clear, and timely for stakeholders. In small teams, the incident lead often writes them.