Updated 25 October 2026 · By the Upcertain team
Investigating
Title: [Service] errors
We are investigating errors on [service]. Some customers may be unable to [action people cannot do]. Next update by [time, time zone].Publish this within 10 to 15 minutes of confirming customers are affected, even before you know the cause.
Identified
We have found the cause: [plain description, e.g. a database server ran out of disk space]. We are [fix in progress]. [Service] remains [degraded / unavailable]. Next update by [time].Monitoring
A fix is in place and [service] is working again. We are watching it closely. If you still see problems, please contact [support address].Resolved
This incident is resolved. Between [start] and [end] ([duration]), [what customers experienced]. The cause was [plain cause]. We are [one change to prevent it]. We are sorry for the disruption.Degraded, not down
Title: Slow responses on [service]
[Service] is working but slower than usual, and some requests may time out. Your data is safe. We are [what you are doing]. Next update by [time].Use this when the service works for most people but not well. Saying it plainly stops customers from assuming the worst and opening tickets.
Scheduled maintenance
Title: Scheduled maintenance on [service]
On [date] from [start] to [end] [time zone], [service] will be [unavailable / read-only / slower] while we [work]. [What customers should do, if anything.]Post-incident note
What happened: [two sentences]
Impact: [who, what, how long]
Timeline: [detected, acknowledged, fixed, resolved]
Cause: [plain cause]
What we are changing: [one to three items, with owners]Rules that make them work
- Say what customers notice, not your internals: "checkout fails", not "pod eviction on node-7".
- Always give the next update time, and keep it even if there is no news.
- Use the same time zone in every update, and name it.
- Never guess the cause in public; "we are investigating" is honest.
- Apologise once, in the resolved update.
Publishing them in Upcertain
From an incident, use Post status update to publish to the status pages that show the affected monitor; subscribers receive it by email. Maintenance notices go out as announcements of the type Maintenance, and planned windows appear on the page ahead of time. See subscribers and incident response for small teams.
Questions
How often should we post updates?
Every 30 minutes during a major outage, or at whatever interval you promised in the last update, even if the only news is that you are still working on it.
Who should write the updates?
Someone other than the person fixing the problem, if you have two people. The person fixing it should not also be writing to customers.
Should we email subscribers for every update?
For incidents customers notice, yes: investigating, resolved, and any update that changes what they should do. Short incidents that resolved before anyone noticed may only need the resolved note on the page.
What should the resolved update avoid?
Blame, guesses and internal jargon. Say what customers experienced, for how long, the cause in plain words and one thing you are changing.