What to Put on a Status Page During an Incident

Your site is down. Customers are refreshing, tweeting, and emailing support. They go to your status page and see: "All systems operational." Now you have two problems.

Status pages are supposed to build trust during the worst moments for your service. But most teams either update too late, say too little, or write updates that make customers more anxious instead of less.

The First Update: Acknowledge Fast

Speed matters more than detail in the first update. Within minutes of detecting an issue, your status page should say something. It does not need to explain everything. It needs to say "we know."

This does three things:

• Confirms you are aware of the problem
• Tells customers which part of the service is affected
• Sets the expectation that more updates are coming

What to Include in Updates

Current Impact

Tell customers what they are experiencing, not what broke internally. "Users may be unable to log in" is useful. "The authentication microservice lost connection to the Redis cluster" is not.

What You Are Doing

One sentence about the action being taken. "We are working to restore database connectivity" or "We have identified the issue and are deploying a fix." Customers want to know someone is actively working on it.

Expected Timeline (If Known)

Only include this if you have reasonable confidence. "We expect to have a fix deployed within 30 minutes" is helpful if true. If you don't know, say "We will provide another update within 30 minutes" instead of guessing a fix time.

What Not to Include

• Internal system names that mean nothing to customers
• Blame (vendor outage, team mistake, third-party API)
• Excessive technical detail about root cause
• Marketing language ("we take reliability seriously")
• Apologies before the problem is fixed (save that for the postmortem)

Update Frequency

The right cadence depends on the severity and duration of the incident:

• First 30 minutes: Update every 10-15 minutes, even if there is nothing new. "Still investigating. No change in status." is better than silence.
• After 30 minutes: Update every 20-30 minutes. Include any new information about scope, impact, or ETA.
• Extended incidents (1+ hours): Update every 30-60 minutes. At this point, customers have adjusted. They just want to know when it will be fixed.

The Resolution Update

When the incident is resolved, your final update should include:

1. Confirmation that the issue is resolved
2. Brief summary of what happened (one or two sentences)
3. How long the incident lasted
4. Whether you will publish a postmortem (and when)

Automating Status Page Updates

The hardest part of status page communication is doing it while you are also trying to fix the problem. Automation helps:

• Auto-detect: Link your monitoring to your status page. When a check fails and triggers an incident, the status page component updates automatically.
• Auto-resolve: When monitoring confirms the service is back, update the status page automatically.
• Templates: Pre-written update templates for common incident types save time during the incident.

In upti.my, incidents automatically update your status page when they are created and resolved. You can add manual updates during the incident for additional context, but the basic communication happens without you lifting a finger.