> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sitepulse.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Check tools
> What the five check tools measure, how on-demand and automatic checks differ, and how to read results
Sitepulse watches your sites with five different checks, each looking at a different part of website health. They run against the [sites](/guide/sites) your team has added, and every plan includes all five.
## The five tools
Whether the site is reachable, which HTTP status code it returns, how long it takes to respond, and whether redirects are working.
Whether the TLS certificate is valid, who issued it, and when it expires.
Which DNS records are published and whether the domain appears to be proxied through Cloudflare.
Which links on the site return unsuccessful responses.
How quickly the page loads, Core Web Vitals, performance score, and suggested improvements.
## On-demand vs automatic checks
**On-demand checks** run when you ask for them, for an answer right now. Status and DNS usually come back in seconds; SSL, broken links, and performance can take longer and may finish in the background - when they do, Sitepulse lets your team know whether it succeeded or failed. On-demand checks are saved to the site's history, but they **never open or resolve issues**.
**Automatic checks** run on their own schedule, set in [team monitoring settings](/guide/monitoring) (or overridden per site). These are the ones that watch for trouble: when a site keeps failing or crosses one of your thresholds, Sitepulse opens an [issue](/guide/issues) and alerts the people you've chosen. When things recover, the issue closes itself and a recovery alert goes out.
In the dashboard, on-demand check access depends on your plan's tools and how many on-demand checks your team has left this month. All team members can run dashboard on-demand checks when quota remains, even when that tool's automatic schedule is off for the site. Dashboard checks are not held back by automatic cadence limits, though a tool that is already pending for the site still needs to finish first.
Performance is the only tool that allows you to choose a **page URL** to check a specific page (for example `https://example.com/pricing`) instead of the site's root URL.
## Running on-demand checks
You can run on-demand checks from:
* A site's **Run Check** menu, which queues the selected check and opens its detail page
* A tool page for SSL, DNS, Status, Broken Links, or Performance
* The API, when your token has permission
From a tool's page, pick a site from your team. For Performance, you can also point the check at a specific page - it just has to be on the same domain as the site.
API-triggered checks keep their own per-site, per-tool cadence guard in addition to API rate limits.
Some checks take a little longer and show as **pending** at first. The check detail page updates automatically when the result is ready.
### Linking straight to a check
If you have a check's ID (from the API or a webhook), this link opens it directly:
```
https://app.sitepulse.dev/check-link/{check-uuid}
```
It jumps to the check detail on the site page - handy for runbooks or integrations that want to deep-link to a result.
## Problem thresholds
Thresholds are how you tell Sitepulse what "a problem" means - for example, how many failed status checks in a row count as an outage, or how many days before a certificate expires you want a heads-up.
You'll find every threshold explained per tool in [Monitoring settings](/guide/monitoring#issue-settings). Your defaults apply to the whole team, and any single site can [use its own](/guide/sites#site-specific-overrides).
## Reading results
Mean the request failed or returned an HTTP response code selected under **Status codes that count as an incident**. A connection error or timeout always counts as a failure.
Usually mean the certificate is expired, missing, misconfigured, or not yet trusted.
Usually mean required records are missing or changed.
Identify pages or URLs that need cleanup.
Identify slow responses, poor Core Web Vitals, or optimization opportunities.
### HTTP status code 0
A status of `0` isn't a real HTTP code - it's Sitepulse's way of saying it couldn't get any response from your site at all.
This usually points to a connection problem rather than the site itself returning an error: a DNS failure, a connection that timed out or was refused, a TLS handshake that didn't complete, or a URL that Sitepulse won't connect to for safety reasons.
Status `0` always counts as a failed status check for incident evaluation.
If the first connection attempt can't be established, Sitepulse automatically tries again over IPv4. This catches the common case where a domain advertises an IPv6 address that isn't actually reachable.
## Check status values
| Status | Description |
| ----------- | ---------------------------- |
| `pending` | Queued or currently running |
| `completed` | Finished successfully |
| `failed` | Finished with error |
| `skipped` | Not run due to configuration |
## Run reasons
Automatic status checks can include a run reason:
| Run reason | Meaning |
| -------------------- | ------------------------------------------------------------------------ |
| `scheduled` | Normal automatic cadence run |
| `confirmation_retry` | Follow-up run used to confirm an apparent outage before opening an issue |
| `incident_follow_up` | Follow-up run while a status issue remains active |
On-demand checks usually have `run_reason: null`.