How to Write a Status Page Update in English

A status page update is often the first and only thing a customer reads during an outage, and its wording shapes whether they trust that the team has things under control or assume the worst. Learning the standard vocabulary and phrasing for each stage of an incident — investigating, identified, monitoring, resolved — makes it much easier to write updates quickly and consistently under pressure.

Key Vocabulary

Investigating — the initial incident status indicating the team is aware of a problem and actively working to understand it, but doesn’t yet have a confirmed cause. “We’re marking this as Investigating because we’ve confirmed elevated error rates but haven’t isolated the exact cause yet.”

Identified — the status update once the team has found the root cause or the specific component responsible, even if a fix isn’t deployed yet. “We’ve moved this to Identified — the issue is a database connection pool exhaustion, and we’re now working on a fix.”

Monitoring — the status indicating a fix has been applied and the team is watching metrics to confirm the issue is fully resolved before declaring it closed. “We’ve deployed a fix and moved to Monitoring — error rates have returned to normal, and we’re watching for at least thirty minutes before closing this out.”

Resolved — the final status confirming the incident is over and normal service has been restored, typically including a brief summary of impact and duration. “This incident is now Resolved. Impact lasted approximately 45 minutes and affected checkout for a subset of users. A detailed postmortem will follow.”

Affected components — the specific services or features called out as impacted, allowing customers to quickly check whether the incident applies to what they’re using. “Affected components: Checkout API, Payment Webhooks. Dashboard and Reporting were not impacted.”

Writing Each Stage

• Investigating: “We are currently investigating reports of elevated error rates on [component]. We will provide an update within [timeframe].”
• Identified: “We have identified the cause as [brief, honest description] and are working on a fix. Next update in [timeframe].”
• Monitoring: “A fix has been implemented and we are monitoring the results. [Component] appears to be operating normally.”
• Resolved: “This incident has been resolved. [Component] operated normally as of [time]. We apologize for any inconvenience and will share a follow-up summary.”

Keeping a Consistent Cadence

• “Even if there’s no new information, post an update at the promised interval — ‘still investigating, no new findings yet’ is better than customers wondering if anyone is looking at all.”
• “Avoid vague reassurance without specifics — ‘we’re aware and looking into it’ should always be followed, as soon as possible, by what specifically was found.”
• “Keep each update’s tone calm and factual, and avoid speculating about root cause publicly until it’s actually confirmed internally.”

Professional Tips

1. Update on a predictable cadence, even with no news. Silence during an incident reads as inaction to customers, even if the team is working hard — a scheduled “no update yet, still investigating” post maintains trust.
2. Never speculate publicly before confirming internally. Naming a suspected cause too early, only to retract it in the next update, damages credibility more than simply waiting until it’s confirmed.
3. Always close the loop with a resolved update and a promised follow-up. Customers remember whether an incident ended cleanly with a summary, or just faded out with the status page quietly going green.

Practice Exercise

1. Write a status page update for the Investigating stage of a hypothetical incident affecting a login service.
2. Draft the Identified and Monitoring updates for the same incident, assuming the cause was a misconfigured load balancer.
3. Write the final Resolved update, including approximate duration and affected components.