> For the complete documentation index, see [llms.txt](https://docs.statuspal.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.statuspal.io/next/monitoring/connect-checks-to-status-pages.md).
# Connect checks to status pages
Link a monitoring check to a status page service so outages open and resolve incident notices on their own, and show live response times to your visitors.
A monitoring check on its own alerts your team. Connected to a status page, it also keeps your customers informed: when the check goes down, the linked service changes status and an incident notice is published, and when it recovers, both are put back without anyone touching the dashboard.
{% hint style="info" %}
**This creates status page notices, not Incident Management incidents.** A connected check publishes an incident notice on your status page for subscribers. It never declares an Incident Management incident, so no responders are paged, no Slack channel opens, and no runbook runs. To coordinate your internal response, declare an incident yourself.
{% endhint %}
## Automate service status and incident notices
Open a check from **Monitoring → Checks**, choose **Edit check**, and switch on **Status page automation**. Two fields appear:
* **Status page**: the page whose service this check should drive. Only pages you have access to are listed.
* **Service**: the service on that page, shown together with its container, for example "API → EU". If a service sits in several containers, each combination is a separate option, so pick the one this check actually probes.
Save the check. From now on, the check's up and down periods drive that service.
**When the check goes down**, after failing for longer than its down threshold:
1. An incident notice titled **Automated Incident** is published on the status page with the status **Investigating**, the service marked as **Degraded**, which becomes the service's status, and a first update reading "Incident created by monitoring check."
2. The check's notification recipients receive their alert email as usual.
If an incident notice is already open for that service, no second notice is created and the service keeps the status that notice gave it. The check joins the notice that is already there and does not change how the service looks, so a service you marked **Unavailable** by hand stays Unavailable.
**When the check recovers**:
1. The linked service is set back to **Operational**.
2. Every open incident notice affecting that service receives a **Resolved** update reading "Incident resolved by monitoring check."
{% hint style="info" %}
**Automated notices do not notify subscribers.** The notice and its updates appear on the status page, but no email or Slack message goes out and the RSS feed skips them. Your check's notification recipients are the only people alerted. If subscribers should hear about it, open the notice and post an update with **Notify subscribers** ticked.
{% endhint %}
The automated notice is an ordinary notice. While it is open you can rename it, post your own updates, and adjust the impact from the notices list, and the check will still resolve it when the endpoint comes back. See [Incident, Maintenance & Info Notices](/next/status-pages/incident-maintenance-and-info-notices.md) for everything you can do with a notice.
{% hint style="warning" %}
**Tune the down threshold before connecting a check.** Every Down period becomes a notice on your status page. A threshold of 0 publishes an incident on the first failed probe, which turns a single network blip into a published outage. The default of 5 minutes is a sensible starting point. See [Configure checks](/next/monitoring/configure-checks.md).
{% endhint %}
There is no status-only mode for checks: a connected check always publishes a notice alongside the status change. If you want status changes without notices, use an incoming webhook automation instead. See [Automate status updates](/next/status-pages/automate-status-updates.md).
## Display response time charts on your status page
With Status page automation on, a third option appears: **Display response time chart**. Switch it on to publish the check's response times on the status page, right below your services. Visitors see the same measurements you see on the check page, averaged across the regions that probe the endpoint.
The chart is titled after the check, in the form "*Check name* Response time", so a check named "Test" shows up as "Test Response time". Name checks the way you want customers to read them. Each chart offers **Day**, **Week**, and **Month** views, opens on Day, and shows the average for the selected period in its corner. Periods with no measurements yet display a short "No data available" message instead of an empty chart.
You can switch on the chart for as many connected checks as you like. Each one gets its own chart on the page. Turning the toggle off, or disabling Status page automation, removes the chart immediately while the check keeps running.
The chart reads the same data as the **Response time** panel on the check page, with one difference in the periods offered: the check page goes down to the last hour, the status page chart goes up to a month. See [Understand check results](/next/monitoring/understand-check-results.md) for how the measurements are taken.
