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:
- Do you know about it? The client should never be the one to tell you the site is down.
- What is affected? “The checkout page” is a very different message from “the whole site”.
- When will you say more? Not when it will be fixed, because you may not know. When the next update comes.
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.
Frequently asked questions
How often should I post updates during an incident?
Say when the next update will come and keep to it, even if the update is 'no change'. A regular rhythm calms people more than a long explanation.
Should an incident update say what caused the problem?
Not at first. During the incident, say what is affected and what you are doing. Explain the cause once it is fixed and you are sure of it.
Related
Monitor your first site free
30 monitors free, checks from 2 regions, no card. SSL and domain expiry from $7 a month.