Incident update cadence is the rhythm at which a team communicates during an active issue. A good cadence reduces uncertainty without forcing responders to publish noise every few minutes.
If you want the feature side, see Incident management and Create a public status page. This guide focuses on communication timing.
Industry surveys find that customers consistently rate “lack of updates” as the top communication failure during incidents — more frustrating than the outage itself. Based on operational experience at StatusPage.me, the support ticket volume during an incident drops noticeably once a team starts posting predictable updates with a stated next-update time, even if the update itself contains no new technical information.
Why cadence matters
Customers do not expect instant resolution. They do expect predictable communication.
When cadence is weak:
- customers assume silence means the team is lost
- support volume rises
- internal stakeholders start asking for ad hoc updates everywhere
Cadence should follow severity
| Severity | Typical cadence | | ----------------- | ---------------------- | | Major outage | Every 10 to 15 minutes | | Partial outage | Every 15 to 30 minutes | | Minor degradation | Every 30 to 60 minutes |
Current impact: [what customers may see] Current action: [what the team is doing now] Next update: [time]
The easiest starting model is to tie cadence to incident severity.
| Severity | Typical cadence |
|---|---|
| Major outage | Every 10 to 15 minutes |
| Partial outage | Every 15 to 30 minutes |
| Minor degradation | Every 30 to 60 minutes |
For the severity model itself, see Incident severity levels.
Predictability matters more than volume
A useful update cadence is not just “more updates.” It is a predictable promise that the team actually keeps.
Customers should know:
- when the next update is expected
- whether the team is still investigating, mitigating, or monitoring
- whether the impact has changed
If the incident is escalating operationally too, the communication cadence needs to stay aligned with responder coordination. See On-call escalation policies explained.
What every update should do
Even when there is no full resolution, an update can still provide value by clarifying:
- current impact
- what changed since the last post
- what the team is doing now
- when the next update will arrive
For copy examples, see Incident communication templates.
Automation vs manual updates
Automated updates work well for the initial detection moment — when a monitor confirms a failure, an automatic “Investigating” post on your status page is faster than waiting for a human to notice the alert and manually publish. That speed matters. For everything after detection, manual updates are usually better because automated messages cannot explain what the team is doing, what the scope is, or when the next update will arrive. The risk with over-automating cadence is that customers get status page noise without the context that actually reduces their uncertainty. A practical model is to automate the opening post and resolution confirmation, and keep the in-between updates human-written with a committed next-update time. For incidents where the situation is still unclear, an honest “still investigating” from a person lands better than a templated automated ping.
How StatusPage.me handles this
Incident management on StatusPage.me lets you publish updates manually from the dashboard or through the API, so your team can write the right update for the moment rather than rely on fixed automated text. The status page displays a visible next-update commitment alongside each post, which holds your team accountable to the cadence you set and gives customers a concrete expectation. For automated opening posts, monitor alerts can trigger an incident creation directly, cutting the time between detection and the first customer-visible update. You control which incidents are public and which stay internal, so degradations that resolve quickly do not create unnecessary noise on your status page.
FAQ
How often should teams update a status page during an outage?
It depends on severity, but major customer-visible outages often need updates every 10 to 15 minutes until the situation stabilizes.
Should teams post an update even if there is no breakthrough?
Yes. If the promised update time arrives, customers still need confirmation that the incident is active and being worked.
What is the biggest mistake in incident update cadence?
Promising a cadence and then failing to keep it. That damages trust faster than a slower but reliable schedule.
