HTTP checks
An HTTP check sends a request to a URL on a schedule, asserts on the response, and notifies you when something is wrong.
When to use HTTP checks
Section titled “When to use HTTP checks”- A website or web app you want kept online.
- A REST or GraphQL API you publish to customers.
- A webhook receiver that needs to be reachable.
- Internal services with public health endpoints.
For a service with no HTTP server, use a TCP port check on its port or a ping check on its host. For a box that can call out but cannot be reached from the internet, use a cron heartbeat the box pings.
How it works
Section titled “How it works”Every HTTP check has a schedule (5 minutes by default in the dashboard; intervals under 5 minutes, down to 30 seconds, need a paid uptime plan) and a target URL. On each tick:
- Site Qwality issues the configured HTTP request from each check location you selected (see default locations).
- Each response is evaluated against your assertions: status code, response body keyword search, response time. With several locations,
min_healthy_regionsdecides how many must pass. - If the result differs from the previous status (e.g., success → failure), the monitor’s notification groups send an alert. If the monitor is linked to a service that opens incidents automatically, an incident also opens and pages through the service’s escalation policy.
- The result is recorded for uptime/latency dashboards and historical reporting.
The dashboard and Slack alerts show the website’s icon next to the check. Site Qwality Monitor fetches it from the site about once a month.
A single HTTP check can also automatically provision a paired:
- TLS check: tracks the certificate’s expiry and alerts when browsers would reject it.
- Domain expiry check: tracks the registrable domain’s registration at its registry. It does not resolve DNS.
- Page-speed check: runs Lighthouse against the URL on a slower schedule.
What you can configure
Section titled “What you can configure”| Concern | Settings |
|---|---|
| Request | method, URI, custom headers, request body, content type, follow-redirects |
| Auth | Basic, Digest, or Bearer token |
| Assertions | success/failure status code lists, keyword search (substring or regex, optionally case-sensitive or inverted), JSON path, timeout |
| Schedule | run interval, check locations and minimum healthy locations (intervals under 5 minutes and more than one location need a paid uptime plan) |
| Notifications | one or more notification groups |
Next steps
Section titled “Next steps” Quickstart Create your first HTTP check and test its alert.
Settings reference Every field on an HTTP check, explained.
API: Create HTTP monitor The underlying POST /http/job endpoint.