AWS, Google Cloud and Azure
Check from a different network than the one your site runs on. The locations page lists every city and provider.
Check your site from several cities and three clouds at once. Choose how many locations must fail before anyone is paged.
Choose from 30 locations in 20 countries and territories.
Every location you select runs the same check on the same schedule, so the only difference between them is the network. You decide how many must pass, so a problem on one network path doesn’t page you on its own.
Check from a different network than the one your site runs on. The locations page lists every city and provider.
Set the minimum number of locations that must pass. With three locations and a minimum of two, a failure in one location is recorded but the monitor stays up.
Each check result records the location that ran it, so you can see whether a failure happened everywhere or in one place.
Every location you select runs on every check, as often as every 30 seconds.
When bot protection such as a Cloudflare challenge refuses a check, the result says so instead of showing a bare 403. A secret header lets our checks through.
A dropped connection is retried before any result is written, and every check times DNS, connect, TLS, first byte and download separately.
On paid uptime plans, a new monitor can start on two locations on different cloud providers, so a bad day at one provider doesn’t look like your outage.
Add a secret header to the monitor and let requests that carry it through your firewall or bot protection. Our User-Agent works too.
site-qwality-check/1.0cloud providers to check from
continents to check from
fastest interval, from every location you select
timing phases recorded on every check
From the cities on our locations page, across AWS, Google Cloud and Microsoft Azure. Pick locations near your users, and add another cloud to compare network paths.
As many as you like on each monitor with a paid uptime plan, and one per monitor on the free plan. See pricing.
Each location a check runs from counts as one check, so a monitor checked from three locations every minute uses three checks a minute. A browser check uses its minutes in every location it runs from.
You set how many locations must pass. If fewer pass, the monitor goes down and alerts. A location that cannot report at all, because of a problem at its provider for example, is left out rather than counted as a failure.
Browser checks run from the AWS locations, and as with HTTP checks you choose how many must pass before the check alerts.
No. A secret custom header or our User-Agent, site-qwality-check/1.0, lets checks through from every location. If your firewall needs an IP list, we provide fixed or dedicated IP addresses: contact us. The allowlisting guide walks through each option.
The site’s bot protection, such as a Cloudflare challenge, refused our check. Allowlist our checks with a secret header so the protection lets them through.
A monitor that shares a server or network with what it watches goes down with it and cannot tell you. Checking from other networks avoids that. The Uptime Kuma alternative page covers running a self-hosted monitor inside your network and Site Qwality from outside.
Uptime, cron, synthetic, logs, RUM, incidents, and status pages. Free tier on every product.