> ## Documentation Index
> Fetch the complete documentation index at: https://checkly-422f444a-codex-document-usage-api.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Status Pages Overview
> Create status pages to communicate service health, incidents, and maintenance to your customers, with automated incidents and custom branding.
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.
Older pages built from cards and services are deprecated but keep working — see [Status pages v2 (deprecated)](/communicate/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.
## Component status and impacts
Each component has one of five statuses:
| Status | Meaning |
| -------------------- | --------------------------------- |
| Operational | Everything works |
| Under maintenance | Planned maintenance is running |
| Degraded performance | Slow, but working |
| Partial outage | Some functionality is unavailable |
| Major outage | The component is down |
A component's status is set by open [incidents](/communicate/status-pages/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`](/constructs/status-page-v3-automation-rule) construct.
Incident automation is available on Communicate Team and Enterprise plans. [View pricing](https://checklyhq.com/pricing)
## Uptime calculation
Uptime is calculated over the **last 90 days**, per component, from incident impacts:
* **Major outage** time counts as full downtime.
* **Partial outage** time counts as 30% downtime.
* **Degraded performance** and **under maintenance** do not lower uptime.
```
Uptime = ((Total time - Weighted downtime) / Total time) × 100
```
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.
## Monitoring as code
Status pages, components, and automation rules can be fully managed with the Checkly CLI. See the [`StatusPageV3`](/constructs/status-page-v3) construct. `checkly import status-page:` imports an existing page with its components and rules into your project.
## 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.