Sites and checks

1. Open Sites → Add Site and enter a public HTTP or HTTPS URL. Private and internal addresses are refused.
2. Select the checks to create and how often each runs. If you select none, an HTTP check that runs every five minutes is created.
3. Open the site to inspect results, response times, incidents and regions.

Check types

| Check | What it verifies | Intervals offered on the site form | |-------|------------------|------------------------------------| | HTTP | Status code, and optionally the method, headers, body, body text and response headers you set | 1, 5, 10, 15 or 30 minutes, or 1 hour | | Ping | Reachability and round-trip time of the host | 1, 5, 10, 15 or 30 minutes | | DNS | The host's DNS records; a change from the last observed records raises an alert | 5, 15 or 30 minutes, or 1 hour | | TLS certificate | Certificate validity and expiry | 1, 6, 12 or 24 hours |

The shortest interval your plan allows is one minute during the trial and on paid plans. An interval must be a whole number of minutes, at most 24 hours. Through the API, check intervals are set in seconds, from 60 to 86400.

A site holds at most one check of each type. More check types are set up separately: Heartbeats for scheduled jobs, Laravel application health checks for an application health endpoint, and broken-link scans from the site page.

Alerts from checks

• HTTP, ping and DNS results come from edge pollers. A failure opens an incident only after confirmation; see Incidents and quorum.
• Ping packet loss: a ping fails when more than 20 % of the echo replies are lost. A link that always drops a few packets can raise this per check, 0 to 100 %, through the API setting max_packet_loss; 100 fails only on total loss.
• TLS expiry: HTTP checks read the certificate expiry date. One alert is sent when the certificate comes within the threshold (14 days by default; 1 to 365 days through the API setting tls_expiry_threshold_days), and a renewed alert when it leaves it.
• DNS changes: the first successful observation sets the baseline. A later change sends a DNS changed alert, and a return to the baseline sends DNS restored.
• Broken links, mixed content, TLS scan findings and application health send informational issue and resolved alerts. They do not open downtime incidents.
• Performance: when enabled on an HTTP check, the average response time of the last 15 minutes is compared with the last two hours. Per region, an alert is sent when it is slower by more than the threshold (50 % by default), with at least ten measurements in each window. Only email and Telegram deliver performance alerts.

Missing measurements mean unknown health, not proof of uptime. Domain-expiry alerts, customer TCP-port checks, Lighthouse audits and browser journeys are not available.

If a site fails only from pollers, review its firewall and CDN rules and the Poller IP and region allow-list article. Do not expose private networks or remove authentication to make a check pass.