Customers usually forgive an outage. They remember whether you told them what was happening, whether it was true, and whether you said when they'd hear from you next. Getting this right is mostly a matter of a fixed structure and a fixed schedule.
What an update contains
- That you know about the problem and are looking into it.
- What is affected and who notices, as precisely as you can say.
- What you're doing right now, in plain words.
- When the next update will be, even if it's only to say nothing has changed.
The stages of an incident
Most incidents move through four states. Investigating: something is wrong and you're looking. Identified: you've found the cause. Monitoring: a fix is in and you're watching it. Resolved: it's over, with a short note on what happened. Posting at each stage, even briefly, gives customers a clear sequence to follow.
Templates
- Investigating: We're investigating errors affecting [area]. Some [users/requests] may see [symptom]. Next update by [time].
- Identified: The cause is [plain description] and we're working on a fix. [Area] is still affected. Next update by [time].
- Monitoring: A fix is in place and [area] is recovering. We're watching to confirm it holds and will resolve once it's stable.
- Resolved: This was resolved at [time]. The cause was [short description]. We're sorry for the disruption and will follow up with any longer-term fixes.
Tone
Say what you can verify and stop there. Don't promise that data is safe, don't guess at a fix time, and don't make the problem sound smaller than it is. When a provider you depend on is the cause, name them.
Cadence
Choose an interval and stick to it. A "no change yet, still working on it" update at the promised time is better than silence. Let customers subscribe so updates reach them without refreshing the page.