Skip to main content
A good status page builds trust by being transparent about service health. It’s the single source of truth for customers during incidents and the historical record of your reliability.

​
Core elements

​
Component list

Break your service into components that users understand:
ComponentDescription
APICore REST API
DashboardWeb application
WebhooksEvent delivery
AuthenticationLogin and token management
Components should map to things users interact with, not internal architecture. “PostgreSQL cluster” means nothing to a customer — “Database” or even just “API” is better.

​
Component status

Each component has a status:
StatusMeaning
OperationalEverything is working normally
Degraded performanceSlower than usual but functional
Partial outageSome functionality is unavailable
Major outageService is down
MaintenancePlanned maintenance in progress

​
Incident history

A timeline of past incidents, including:
  • What happened
  • Duration
  • Root cause (brief)
  • Resolution
This builds credibility. A status page with no incident history feels dishonest — every service has incidents.

​
Uptime metrics

Display historical uptime percentages:
  • Last 7 days, 30 days, 90 days
  • Per component or as an aggregate
  • Visual timeline showing green/yellow/red periods

​
What makes a good status page

​
Honest and timely

Update the page within minutes of detecting an issue. Don’t wait until you have a full diagnosis.

​
Written for customers

Use language your customers understand:
  • “API response times are elevated” ✓
  • “Ingestion pipeline backpressure on Kafka partition 7” ✗

​
Subscribable

Let users subscribe to updates via:
  • Email notifications
  • RSS/Atom feeds
  • Webhook integration
  • SMS (for critical services)

​
Separate from your infrastructure

Host your status page on a different provider than your main service. If your cloud provider goes down, your status page should still be accessible.

​
Incident update cadence

PhaseUpdate frequency
First detectionImmediately
InvestigationEvery 15–30 minutes
Fix appliedImmediately
MonitoringEvery 30 minutes
ResolvedFinal update
Even if nothing has changed, post an update: “We are continuing to investigate. No new information at this time.”

​
Status Data in DevHelm

DevHelm’s Status Data feature tracks third-party service health, which feeds into your own status page decisions — if a dependency is down, your status page should reflect that impact.

Status Data overview

Track third-party service health.

Communication during incidents

Best practices for incident communication.