DEV Community

Cover image for How to write an incident update clients read
not the same
not the same

Posted on Edited on Originally published at tenium.app

How to write an incident update clients read

Originally published on the Tenium blog. I'm the author of Tenium, an uptime monitor for agencies.

During an outage the client is not reading your update for information. They are reading it to decide whether to panic. A good update answers that question in the first line, and every line after it supports the answer.

The three questions

Every incident message should answer these, in this order:

  1. Do you know about it? The client should never be the one to tell you the site is down.
  2. What is affected? "The checkout page" is a very different message from "the whole site".
  3. When will you say more? Not when it will be fixed, because you may not know. When the next update comes.

An incident timeline: investigating, identified, monitoring, resolved

A structure that works

Four short parts are enough:

  • Status: Investigating, Identified, Monitoring or Resolved. Four words the client learns once.
  • Impact: what a visitor sees right now, in their words.
  • Action: what you are doing about it.
  • Next update: a time.

An example: "Investigating. Visitors see an error page on the shop. We know about it and are checking the server. Next update by 14:30."

Things to avoid

  • Guessing the cause. "Probably the host" is wrong often enough to hurt. Say what you know.
  • Promising a fix time you do not control. Promise an update time instead.
  • Technical vocabulary. If you must use a term, explain it once.
  • Silence. An hour without a message looks like an hour of nothing happening, even when it is not.

After the incident

Close the loop with a short summary: what happened, how long it lasted, what you changed. Two or three sentences, no blame. The close-out is the part clients remember, and it is where you show the work.

Where to post it

Email works for a client who sits at their desk. A public status page works for everyone else: their customers, their staff and the person who just wants to check without writing to you. On a Tenium status page each incident keeps a timeline of updates, so the history is there afterwards, and on Pro and above the page runs on your own domain with your branding. The detail is on the status pages page, and incident management covers how updates are recorded.

If you want the technical side of the first fifteen minutes, read website down: what to do in the first 15 minutes.


If you look after many client sites, there is a free plan (50 monitors): https://tenium.app/?utm_source=dev.to&utm_medium=cross-post&utm_campaign=incident-update

Top comments (0)