Skip to main content
Status pages communicate the health of your services to customers, users, and stakeholders. A status page shows the current status and 90-day history of each component, plus open incidents and planned maintenance. Status page example
Older pages built from cards and services are deprecated but keep working — see Status pages v2 (deprecated). You can migrate a v2 page from its page settings in the Checkly app.

​
Components

A status page is built from components. A component represents a part of your product as your users see it: the web app, the API, email delivery. Components come in two types:
  • Service: a monitored thing with its own status and uptime history.
  • Group: a container that nests services under a shared heading. A group shows the average uptime of its children.
Components belong to one status page. You manage them in the page’s settings, where you can add, nest, reorder, hide, and delete them. For each component you can also hide its historical data, which is shown by default, and you can show a group expanded when the page loads. Groups are collapsed by default, and a group needs at least one component. Component editor

​
Component status and impacts

Each component has one of five statuses: A component’s status is set by open incidents: each incident declares an impact per affected component. The page header shows the worst status across all components.

​
Automatically creating incidents

Automation rules open and resolve incidents based on your checks. A rule matches failing checks by tag: when a check carrying one of the rule’s tags fails, Checkly opens one incident impacting the components the rule lists, and resolves it when the check recovers. Manage rules on the Automation tab of your status page, or in code with the StatusPageV3AutomationRule construct or the checkly_status_page_v3_automation_rule Terraform resource.
Incident automation is available on Communicate Team and Enterprise plans. View pricing

​
Uptime calculation

Uptime is calculated over the last 90 days, per component, from incident impacts:
  • Major outage counts as 100% downtime.
  • Partial outage counts as 30% downtime.
  • Degraded performance counts as 0% downtime as the service is still usable.
  • Under maintenance counts as 0% downtime as it is an intentional pause of service.
Downtime during a maintenance window that covers the component is not counted. A group shows the average uptime of its child components. Uptime is driven by incidents, not directly by check results: without an automation rule or a manually created incident, a failing check does not lower uptime.

​
Plans

Status page features come with your Communicate plan, which is separate from the plan for your checks and monitors. A Team plan for checks doesn’t include the Communicate Team features below. See pricing for limits such as the number of pages and subscribers.

​
Status pages and dashboards

Status pages and dashboards both share health outside the Checkly app, but they answer different questions:
  • Status pages show your services as your customers see them. Each component’s status and uptime come from incidents, which you open manually or with automation rules, so a failing check only affects the page when it opens an incident. Visitors can subscribe to updates.
  • Dashboards show your checks directly: each check’s live status, availability and response times, filtered by tag. Use them for internal teams or technical audiences who want to see the monitoring results themselves.

​
Monitoring as code

Status pages, components, and automation rules can be fully managed with the Checkly CLI. See the StatusPageV3 construct. checkly import status-page:<id> imports an existing page with its components and rules into your project. With Terraform, use the checkly_status_page_v3, checkly_status_page_v3_component, and checkly_status_page_v3_automation_rule resources.

​
Best practices

  • Keep the component list short. A page with a handful of user-facing components reads better than one mirroring your service map.
  • Use groups to aggregate regions or subsystems.
  • Write incident updates in plain language and update them as you learn more. Close incidents with a short explanation of the fix.