Uptime monitoring

Every uptime monitor in Site Qwality follows the same lifecycle: configure → run on schedule → emit results → trigger notifications on state change. What differs is what the monitor checks.

Check type	What it checks	Use for
HTTP	A URL responds with the expected status, body, and latency	Websites, APIs, webhook receivers
TCP port	A port accepts connections, optionally over TLS and with an expected response	Databases, mail servers, SSH, custom protocols
Ping	A host answers ICMP echo requests within your packet loss threshold	Servers, routers, network devices
SSL/TLS	A certificate’s expiry date, and whether browsers accept it	Anything served over HTTPS
Domain expiry	A domain’s registration at the registry: expiry date, registry holds, registrar and nameserver changes	Any domain you would lose if a renewal failed
DNS record	A domain’s records at its authoritative nameservers: changes, missing records, nameservers that disagree	Catching unplanned changes to web, mail and nameserver records
Cron heartbeat	A scheduled job pinged on time	Backups, ETL, batch jobs
Browser	A full Playwright script passes in a real Chromium	Login flows, checkout, multi-page journeys

Picking the right check

• You have a URL that should be 200 OK. Use HTTP checks. Each one also gets a paired TLS check (certificate expiry and validity) and domain expiry check (domain registration) unless you turn them off.
• Your service is not HTTP. Use a TCP port check to connect to its port, optionally over TLS, and match what it sends back.
• You want to know a host answers at all, and how much packet loss it has. Use a ping check.
• You only care about cert expiry. SSL/TLS checks always pair with an HTTP monitor, so create one for the host and keep Monitor TLS/SSL on.
• You want to hear before a domain registration lapses. Enable the domain expiry check on an HTTP monitor for that domain.
• You want to know when a domain’s DNS records change. Create a DNS record monitor for the domain. It runs on its own, without an HTTP monitor.
• You have a cron job that should run every N minutes. Use a cron heartbeat. Your job pings Site Qwality at the end of each successful run, and Site Qwality alerts when it doesn’t.
• You need to validate a multi-step user flow. Use browser checks. You write a Playwright script and Site Qwality runs it on schedule, capturing a HAR and a video of every run.

Cross-cutting concerns

Check locations

HTTP and TCP port checks can run from 30 check locations across 20 countries and territories, on AWS, Google Cloud and Microsoft Azure. Ping checks run from the 8 Google Cloud locations among them, and browser checks from the 20 AWS locations, in 18 countries and territories. Each location is a provider and region combination, so a city can have more than one option. The live list is on the locations page; for API clients, see check locations in the HTTP reference.

• Default. A new HTTP or TCP port monitor runs from aws-us-east-1 (Virginia, AWS) unless you choose, and a new ping monitor from gcp-us-east4 (Virginia, Google Cloud), or gcp-us-west2 (Los Angeles, Google Cloud) while Virginia is unhealthy. On a paid uptime plan, when the extra checks fit the account’s quota, an HTTP or TCP port monitor starts on two locations on different cloud providers and alerts only when both fail; see default locations. Ping runs on one cloud provider, so a ping monitor starts on one location. A new browser check runs from aws-us-east-1 unless you choose.
• Plans. More than one location per monitor needs a paid plan for that check type: a paid uptime plan for HTTP, TCP port and ping checks, a paid Synthetic plan for browser checks.
• Billing. Each location an HTTP, TCP port or ping check runs from counts as one check toward your monthly check volume, and so does each recheck of a failed location. A browser check runs its script once in each location, and each run uses browser check minutes.
• Other check types. SSL/TLS, domain expiry and DNS record checks run from aws-us-east-1 only.

Start with a location near your users. Add another cloud provider when you want to compare network paths, and choose locations on other continents to cover a global audience.

Every selected location runs on each scheduled tick, and min_healthy_regions sets how many of them must pass for the monitor to count as healthy. See location quorum for the details.

To let checks through a firewall or bot protection, or to run them from fixed IP addresses, see allowlisting our checks.

Schedules

Check type	Minimum interval
HTTP, TCP port, ping	30 s (intervals under 5 minutes need a paid uptime plan)
Cron heartbeat	n/a (driven by your job’s ping cadence)
Browser	5 min
TLS, domain expiry (paired with HTTP)	daily, not configurable
DNS record	5 min (the minimum depends on your plan)

Tags

HTTP, cron and browser monitors accept a tags: string[] field. Use tags consistently (service:api, env:prod, team:platform) and you can:

• Match maintenance windows to silence by tag.
• Filter dashboards and alerts by tag.
• Roll up uptime by service or environment.

Services (logical grouping)

Beyond tags, you can attach a monitor to a service (service_id), a higher-level grouping.

Manage monitors over the /v1 API

Monitor type	Routes
HTTP, TCP port and ping	GET and POST /v1/http-monitors; GET, PATCH and DELETE on /v1/http-monitors/{id}; POST /v1/http-monitors/{id}/run
Cron heartbeat	GET and POST /v1/heartbeat-monitors; GET, PATCH and DELETE on /v1/heartbeat-monitors/{id}
Browser	GET and POST /v1/browser-monitors; GET, PATCH and DELETE on /v1/browser-monitors/{id}; POST /v1/browser-monitors/{id}/run
DNS record	GET and POST /v1/dns-record-monitors; GET, PATCH and DELETE on /v1/dns-record-monitors/{id}

curl "https://api.siteqwality.com/v1/http-monitors?limit=50" \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY"

• They take the same fields as /http/job, /cron/job, /browser_check and /dns/record-monitor, and answer in the /v1 shapes: lists newest first as {"data": [...], "next_cursor": "..."}, one monitor as the object itself, errors as application/problem+json. Idempotency-Key works on every POST and PATCH.
• PATCH changes only the fields you send. DELETE answers 204, also when the monitor is already gone.
• Reads need read:monitors, and changes write:monitors.
• Results, events, uptime and SLA reads stay on the older routes for now.

See also

HTTP checks The most common monitor. Request a URL, assert on the response.

TCP port checks Connect to a port, optionally over TLS, and check the response.

Ping checks ICMP echo requests with packet loss, round-trip time and jitter.

SSL/TLS checks Track certificate expiry and validity for an HTTP check's host.

Domain expiry checks Read the registration from the registry and alert before it lapses.

DNS record monitors Watch a domain's records at its nameservers and alert when they change.

Cron checks Receive heartbeats from your scheduled jobs.

Browser checks Real Chromium running your Playwright script.