Reliability

We run on two clouds so your monitoring doesn't die with ours

A monitor is only useful if it's up when everything else is down. So we don't run UptimeTwin on a single server, in a single place, on a single cloud. Here's how it actually works — the same page we'd want to read before trusting a monitoring vendor.

Two independent clouds, always on

Most monitoring tools — and most of the sites they watch — live entirely on one cloud provider. When that provider has a bad day, and they all do, a monitor that lives there goes dark at the exact moment you need it most.

UptimeTwin runs on two completely separate clouds at the same time. Both are actively checking your monitors and both can send alerts. If one provider has an outage, the other simply keeps going — you still get checked, and you still get paged.

Cloud A
Active — checking + alerting
Cloud B
Active — checking + alerting

Both clouds run in parallel. Neither is a cold spare waiting to be switched on — they're both working right now.

Four regions around the world

On top of two clouds, we check from four regions across three continents. On Pro, Business and MSP you choose which region watches each monitor — check your European site from Europe and your US API from Virginia, so response times reflect where your customers actually are.

US West
San Jose, Los Angeles + Dallas
US East
Virginia + Newark
Europe
Amsterdam + Paris
Asia-Pacific
Singapore + Tokyo

Every region runs from at least two datacenters on two providers — US West from three — so a single-site failure doesn't stop the checks there.

We page you when it's real — not for a blip

Anyone can send an alert the first time a request fails. The problem is that the internet is noisy: a dropped packet, a momentary DNS hiccup, a half-second of packet loss. Monitors that alert on the first failure are the reason so many people mute their pager.

We don't. Before we call something down, we require several failures in a row, and for HTTP, TCP, SSL and UDP checks we ask other regions whether they can still reach it. When you do hear from us, the alert already tells you which layer broke.

●
acme-store.com is down
HTTPS check
Three checks in a row failed before we sent this — it's not a one-off blip.
What we checked
✓DNS resolvesacme-store.com → 203.0.113.10
✓Certificate validexpires in 46 days
✗Server responseconnection timed out on port 443
Follow-up note: first look at the cause
DNS is resolving and the certificate is fine, but the server isn't accepting connections. That points at the origin server or its firewall — not your DNS or your network. Worth checking the web server process first.
Started 2 min agoDown threshold: 3 checks
1Confirmed, not a blip
We wait for several failures in a row and, for HTTP, TCP, SSL and UDP checks, ask other regions whether they can still reach it. A momentary hiccup never pages you.
2Tells you where to look
Every alert separates DNS, certificate, and server so you know which layer failed. A follow-up note then gives a plain-language first look at the likely cause, within your plan's AI allowance (Free includes 3 diagnoses a month, after 25 AI uses in its first 14 days).
3Recovery, automatically
When it comes back, you get an all-clear with how long it was down. No guessing whether it's still broken.

We watch our own monitoring, too

Every checker reports its own health and how quickly it can reach our database, from every region. If a region slows down or falls behind, we know before it can affect your alerts — and we can move checks to another region while it recovers. The system that watches your sites is watched just as closely.

See it for yourself

The best proof is the product running in the open. Our live demo watches a set of well-known sites in real time — no signup, no setup.

Watch the live demo →Create your free account