Website checks

Website checks perform HTTP GET requests to public endpoints. Create a Website check, save its target and schedule, then inspect its results.

Option	Meaning and constraints
Name	Required
URL	Full valid HTTP/HTTPS URL reachable on the public network
Expected HTTP response code	An integer from 100 to 599; default 200; compared exactly
Follow redirects	Default off; compare the first response when off, final response when on
Interval	Positive seconds at or above the account’s plan minimum
Probe locations	Available Pingstack regions; one default region is added initially
Healthy and failing location counts	Quorum settings; default healthy requires all, failing requires one
Notification groups	Existing account groups

When redirects are enabled, Pingstack follows at most five hops. Each destination must be public. Too many redirects, DNS failures, connection errors, TLS errors and timeouts appear as failed probe results.

Connection opening and response reads each have a 10-second timeout. This is not a configurable total browser-page-load deadline: redirects and network work can make elapsed duration differ. Pingstack does not render a page or measure Core Web Vitals.

Verify and expand

1. Start with one location and confirm the expected response.
2. Add available probe locations from the check’s locations section.
3. Set quorum counts to match how much regional failure should trigger degradation or downtime.
4. Review per-location results before treating aggregate health as a diagnosis of every region.

A real HTTP status mismatch is a target result. If a network failure occurs while Pingstack’s probe infrastructure is suspect, the sample is recorded but does not change health. Do not equate unchanged health with a fresh success.

Private/internal targets are not supported. There are no customer-configurable request methods, custom request bodies or arbitrary headers in this check form. For WAF rules use verification headers, not a blanket allow rule based on a User-Agent.