Status page updates customers can act on
Publish clear incident and maintenance updates that state what is affected, what is known, and when customers should expect the next update.
Create your status pageA status update is an operational record
A customer-facing update is not a changelog entry and it is not an internal debugging log. It gives customers enough reliable information to decide whether to wait, retry, or adjust their own work.
When the event is unplanned, follow an incident communication workflow. For planned work, publish maintenance windows before the change begins.
Example incident update progression
API requests are returning elevated errors. We are investigating. Next update by 09:30 UTC.
A database connection issue is affecting API write requests. Read traffic remains available while we apply mitigation.
API write requests have recovered and remained stable since 09:35 UTC. We will review the incident timeline and follow-up actions.
What every useful update should contain
State
Investigating, identified, monitoring, resolved, or scheduled maintenance.
Impact
Which components or customer actions are unavailable or degraded.
Action
What the team is doing without exposing speculative internal detail.
Next update
A time commitment so customers do not have to keep refreshing.
Update cadence during an incident
Publish when the state or customer impact changes. During a material unresolved outage, also commit to a reasonable next-update time even if investigation continues.
Customers can receive these changes through status page notifications instead of repeatedly checking the page.
Status updates are not release notes
Product updates explain what changed in a release. Status page updates explain current service health and customer impact. Mixing the two makes outages harder to understand.
For the product surface that publishes and manages incidents, see incident management.