Status Pages vs Alerts: Coordination

Internal alerts and external status updates coordinate.

The distinction

Internal alerts page on-call to fix problems. Status pages tell customers what's happening. Different audiences, different language, different cadence.

Updating one without the other creates either silent outages (alerts fire, status page is green) or fake outages (status page red, no real impact).

Wire both together but keep them separately authored.

When to update the status page

Customer-facing impact confirmed: more than 5% of users seeing degradation. Investigation begins; status page goes to "investigating".

Cause identified: "identified". Mitigation deployed: "monitoring". Confirmed clear: "resolved".

Status pages are not real-time. Updates every 30 minutes are fine; faster suggests a problem severe enough that customer comms should be a person, not a tool.

Automation boundaries

Don't auto-publish from internal alerts to the public status page. False positives become public crises.

Do auto-create draft incidents on the status page from major alerts. The on-call edits the draft, publishes when ready.

Use Statuspage, Atlassian Statuspage, or instatus. All support draft-then-publish workflows.

Language

Status page text is for customers. "We're investigating slow checkout" beats "checkout-api p99 latency above 200ms SLO".

Always include impact: who is affected, what they see, what to do about it (refresh, retry, wait).

Update on a clock. A 10-minute silence reads as panic; even "still investigating" is better than nothing.

Apply this quarter

Audit your last 5 customer-facing incidents. Did the status page reflect them in time? Within 15 minutes is the bar.

Wire your top 3 alert categories into draft-creation on the status page. Resist auto-publish.

Train on-call on status-page voice. The first incident is too late to learn.