Skip to main content
SitePulse includes five check tools for monitoring website health. Checks run against sites that your team has added. All tools are available on every plan.

The five tools

Status

Whether the site is reachable, which HTTP status code it returns, how long it takes to respond, and whether redirects are working.

SSL

Whether the TLS certificate is valid, who issued it, and when it expires.

DNS

Which DNS records are published and whether the domain appears to be proxied through Cloudflare.

Broken Links

Which links on the site return unsuccessful responses.

Performance

How quickly the page loads, Core Web Vitals, performance score, and suggested improvements.

Manual vs automatic checks

Manual checks run on demand for an immediate result. Status and DNS checks usually return quickly; SSL, broken-links, and performance checks can take longer and may finish in the background, in which case SitePulse sends the team a completion or failure notification. Manual results are saved to the site’s check history but never open or resolve issues. Automatic checks run on the cadence set in team monitoring settings (or a site’s cadence override). Automatic results are evaluated against your problem thresholds — when a check repeatedly fails or crosses a threshold, SitePulse opens an issue and notifies the configured destinations. When the problem later clears, the issue resolves and recovery notifications are sent. Manual check access depends on the current team, your role permissions, the site’s enabled tools, and the team’s monthly manual-check limit. If a tool is not included in the team plan, disabled on the site, or the quota is exhausted, SitePulse disables the run action.
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 manual checks

You can run manual checks from:
  • A site’s Run Check menu
  • The dashboard quick actions
  • A tool page under Dashboard -> Tools
  • The v1 API or MCP server, when the token has permission
The tool page lets you choose a site from the current team. For Performance, you can also choose a page URL on the same domain. SitePulse rejects URLs that do not belong to the selected site. Long-running checks may first show as pending. Poll or revisit the check result until it reaches a terminal state. SitePulse provides a redirect URL for linking directly to a check result:
https://app.sitepulse.dev/dashboard/check-link/{check-uuid}
This redirects to the check detail on the site page. Use it in custom integrations or internal runbooks when you have a check UUID from the API or webhook context.

Problem thresholds

Problem thresholds decide when automatic monitoring opens an issue — for example, how many consecutive status failures count as an outage, or how many days before SSL expiry to warn. Thresholds are documented per tool in Monitoring settings. Defaults apply team-wide; individual sites can override them.

Reading results

Usually mean the site is down, blocked, or redirecting incorrectly.
Usually mean the certificate is expired, missing, misconfigured, or not yet trusted.
Usually mean required records are missing or changed.
Identify slow responses, poor Core Web Vitals, or optimization opportunities.

HTTP status code 0

Status code 0 means SitePulse did not receive an HTTP response from the target site. It is not a real HTTP status code. Common causes include DNS failures, connection timeouts, TLS connection errors, refused connections, or a target URL that SitePulse blocks for safety.
For target-site HTTP checks, SitePulse first uses the normal network resolver. If that attempt fails because the connection cannot be established, SitePulse retries over IPv4. This helps when a domain publishes both IPv4 and IPv6 addresses but IPv6 is unreachable from the SitePulse worker.

Check status values

StatusDescription
pendingQueued or currently running
completedFinished successfully
failedFinished with error
skippedNot run due to configuration

Run reasons

Automatic status checks can include a run reason:
Run reasonMeaning
scheduledNormal automatic cadence run
confirmation_retryFollow-up run used to confirm an apparent outage before opening an issue
incident_follow_upFollow-up run while a status issue remains active
Manual checks usually have run_reason: null.