> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devhelm.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Anatomy of a Status Page

> What makes an effective public status page — components, updates, and notifications

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:

| Component      | Description                |
| -------------- | -------------------------- |
| API            | Core REST API              |
| Dashboard      | Web application            |
| Webhooks       | Event delivery             |
| Authentication | Login 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:

| Status                   | Meaning                           |
| ------------------------ | --------------------------------- |
| **Operational**          | Everything is working normally    |
| **Degraded performance** | Slower than usual but functional  |
| **Partial outage**       | Some functionality is unavailable |
| **Major outage**         | Service is down                   |
| **Maintenance**          | Planned 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

| Phase           | Update frequency    |
| --------------- | ------------------- |
| First detection | Immediately         |
| Investigation   | Every 15–30 minutes |
| Fix applied     | Immediately         |
| Monitoring      | Every 30 minutes    |
| Resolved        | Final 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.

<CardGroup cols={2}>
  <Card title="Status Data overview" icon="globe" href="/status-data/overview">
    Track third-party service health.
  </Card>

  <Card title="Communication during incidents" icon="message" href="/learn/incidents/communicating-during-incidents">
    Best practices for incident communication.
  </Card>
</CardGroup>