A good status page should include the current state of customer-visible services, a clear incident timeline, scheduled maintenance notices, and a way for customers to subscribe to updates. If it cannot answer “what is broken, who is affected, and when will you update again?” it is incomplete.
If you want the implementation side, see Create a public status page. This guide focuses on what should actually appear on the page.
1. Overall status
Start with a clear overall state.
Typical states are:
- Operational
- Degraded Performance
- Partial Outage
- Major Outage
- Maintenance
This gives customers a quick read before they scan details.
2. Customer-facing components
Components help customers understand scope.
For a typical SaaS, useful components are:
- Website
- API
- Authentication
- Email delivery
- Webhooks
- Mobile app
Components should match how customers experience the service, not how your infrastructure team labels internal systems.
3. Active incident feed
An active incident feed should include:
- incident title
- affected components
- current status
- timestamped updates
- expected next update time
Example:
| Time | Update |
|---|---|
| 14:03 UTC | Investigating elevated API error rates |
| 14:11 UTC | Identified failed deployment in one region |
| 14:20 UTC | Rollback complete, monitoring recovery |
4. Scheduled maintenance section
Maintenance should not be mixed into normal status text.
It needs its own section with:
- start and end time
- expected impact
- affected components
- completion update
For reusable copy, see Maintenance announcement template.
5. Historical incidents
Customers often check incident history before they ask support or evaluate reliability.
Historical records should stay visible and searchable. That helps with:
- customer trust
- support efficiency
- vendor due diligence
- internal review work
6. Subscription options
A status page should let customers subscribe to updates.
Common channels:
- webhooks
- chat integrations
- RSS, if relevant for technical audiences
Without subscriptions, customers still have to remember to refresh the page manually.
7. Clear timestamps and timezone handling
Every incident and maintenance update needs a timestamp. Otherwise customers cannot tell whether an update is fresh or stale.
Use one consistent time format and make it obvious.
8. A simple incident state model
Most teams only need a few states:
- Investigating
- Identified
- Monitoring
- Resolved
Too many states make updates harder to maintain. Too few make timelines unclear.
9. Product links for deeper context
Operational content should connect back to implementation and product workflows where appropriate.
Useful internal links include:
Minimal status page checklist
| Section | Required? | Why |
|---|---|---|
| Overall status | Yes | Fast top-level signal |
| Components | Yes | Scope and impact clarity |
| Incident updates | Yes | Ongoing communication |
| Maintenance notices | Yes | Planned disruption visibility |
| History | Yes | Transparency and trust |
| Subscriptions | Recommended | Faster customer awareness |
FAQ
What are the most important parts of a status page?
The most important parts are overall status, component status, incident updates, maintenance notices, and incident history. Those cover the main customer questions during operational issues.
Should every service become a component?
No. Only expose components customers can understand and that affect their experience in a meaningful way.
Should a status page include maintenance updates?
Yes. Planned work still affects customers, so it should be communicated with the same clarity as unplanned incidents.