Dev
Incident Status Message Generator
A status-page-style incident update generator that produces copy in the standard investigating, identified, monitoring, resolved cadence used by Statuspage, Better Stack, Instatus, and every SRE team you have ever subscribed to. Pick the stage you are posting, the severity of the incident, the affected service, and the tone you want to strike, and get a ready-to-paste update with a UTC timestamp header, a severity label, and stage-appropriate body copy. Each stage speaks in its own voice. Investigating updates commit to a next-update window without over-promising a fix. Identified updates name a plausible root cause hint and confirm a fix is coming. Monitoring updates describe the deployed mitigation and set a clean-window expectation. Resolved updates close the loop and reference a follow-up post-mortem. Tone shifts the framing — formal keeps it clinical, friendly-transparent sounds like a human wrote it, apologetic leans into acknowledgement of impact. The generator varies word choice on each click so you are not shipping the same three sentences to every subscriber. Use it as a first draft: replace the placeholder cause and service with your specifics before you publish.
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Pick the incident stage you are posting — investigating, identified, monitoring, or resolved.
- Select the severity (critical, major, minor, or maintenance) so the label and framing match the impact.
- Type the affected service name (for example "the checkout API" or "the web dashboard") or leave the default.
- Choose a tone that matches how your company usually speaks to customers.
- Generate, then replace any placeholder cause hint with the actual root cause before publishing to your status page.
Use Cases
- •An on-call engineer drafting the first investigating update within minutes of a page firing, before the root cause is known
- •A support lead posting the identified update once engineering confirms the root cause and needs standard incident-comms phrasing fast
- •An SRE closing out a resolved incident with a post-mortem-forward message on the company status page
- •A founder at a small startup who has no incident-comms template and needs the standard four-stage flow to reference
- •A technical writer building a status-page style guide and sampling wording variations across all four stages and three tones
Tips
- →Post the first investigating update within 5 minutes of confirming a real customer-facing incident — silence is worse than a vague update.
- →Commit to a next-update time in every intermediate message so customers know when to check back, then hit that time even if you have nothing new.
- →For the resolved message on a major incident, always link to or promise a post-mortem — it converts a bad experience into visible accountability.
- →Avoid technical jargon customers cannot act on ("OOM in pod xyz") and lead with impact ("users saw checkout failures").
- →Save the wording variations you like as internal templates so on-call engineers do not have to write incident copy under pressure at 3am.
FAQ
how do I write a good status page update when I do not know the cause yet
Use the investigating stage. State what users are seeing (failed requests, slow responses), acknowledge the impact, and commit to a next-update time you can actually hit — usually 15 to 30 minutes. Do not speculate about the cause until you can identify it, and never promise a fix ETA in the first message.
what is the difference between the identified and monitoring stages
Identified means you know the root cause and are working on a fix. Monitoring means the fix is deployed and you are watching to confirm it holds. The order matters — customers reading the timeline should be able to see a clean progression from problem to diagnosis to fix to stability.
How often should I post updates during an active incident?
Every 15–30 minutes for a critical or major incident, even if there is no new information — silence reads as neglect. "We are still investigating, next update in 30 minutes" is a valid update. For minor incidents, hourly is usually fine. Always post at every stage transition.
should I apologise in every status update
Not necessarily. Repeated apologies in a long incident start to feel hollow. Acknowledge impact clearly in the first and last messages of the incident, and keep the intermediate updates focused on facts and progress. The apologetic tone here is best used for the initial investigating post and the resolved close-out.
Do I need to post a post-mortem after every resolved incident?
For critical and major incidents, yes — customers and often your own contract SLAs expect a public root-cause analysis within a few business days. For minor incidents that lasted under 15 minutes with limited impact, an internal post-mortem is usually enough. When in doubt, publish.
You might also like
Popular tools from other categories that share themes with this one.
Try these next
More free tools from other corners of the catalog, picked by shared themes.