Know when your site breaks.
Paste an address. PingThat checks it every minute and emails you the moment it stops working.
Free while in beta. You confirm your email, and the first real check runs straight away.
- Name lookup19 ms
- Connect2 ms
- Secure handshake9 ms
- Server response150 ms
30-day uptime 100%, 100% of checks covered. Open our status page
Simple unless you need more.
Most sites need a quick answer to one question: is it up? Basic checks give you that with almost nothing to set up.
Add the address
Paste a URL, pick how often to check, and say what counts as healthy: a status code, or text that must appear on the page.
We check from our servers
You see real timings for every check, not sample data. The first one runs while you set up, so you know it works before you rely on it.
Two failures in a row means an alert
One failed check is a question, not an answer. If the next check fails too, an incident opens and you get an email or a webhook.
Two passes in a row means recovered
You get one recovery message with the estimated outage length.
- Address
- https://acmebakery.example/
- Failure
- HTTP status not accepted (503)
- First failed
- 14:02:11
- Confirmed
- 14:03:12
- Observed from
- 2 failed checks in a row
- Incident
- A link to the full evidence page
Want fewer false alarms? Confirm from other regions.
Sometimes one network has a bad moment while your site is fine. With confirmed checks, a failure is verified by two other regions before anyone is alerted. Turn it on per monitor, only where it matters.
One region sees a failure
The monitor shows “Confirming”. Nobody is paged yet.
Two other regions check right away
Fresh checks, not old results. If at least two of the three see the failure within 30 seconds, an incident opens.
If only one region fails, you aren't woken
It's logged as a regional problem. If the others can't answer in time it stays unconfirmed instead of guessing.
Recovery is confirmed too
Two passing checks, plus one from a different region, close the incident.
A simulation of confirmed checks. Confirmed checks need a service running at least three check regions.
Built for the people who look after other people's sites.
Everything grouped by client
Put monitors into clients and projects. Filter the overview and incidents to one client in a click.
Evidence you can forward
Every incident keeps what each region saw, with timings and the failure reason, so you can explain what happened.
Planned work doesn't page anyone
Schedule maintenance windows. Checks keep running and incidents are still recorded; only the alerts are held back.
Alerts that find you
Email and signed webhooks, with retries if your endpoint is down, and a log of every delivery attempt.
On the roadmap: status pages for your clients, branded reports, and checks for logins and forms. Not available yet, and we'll say so when they are.
Straight about what it can and can't tell you.
Estimates are labelled
Outage length is measured between checks, so it's an estimate. Uptime shows only once there's enough data, next to how much of the period was covered.
“No data” isn't “Down”
If our own checks go missing, we show a gap instead of inventing an outage.
Public addresses only
PingThat refuses to check private or internal addresses, and verifies HTTPS certificates on every check.
Questions
Will it catch every outage?
No monitor can promise that. PingThat checks at the interval you choose, so a failure shorter than the gap between checks can pass unseen. Outage lengths are shown as estimates for the same reason.
Basic or confirmed: which should I pick?
Start with basic. It alerts after two failed checks in a row, which is enough for most sites. Choose confirmed for monitors where a false alarm is costly, such as a client's checkout, if your service offers it.
What if PingThat itself has a problem?
It says so. If checks stop arriving, a monitor shows “No data”, never a false “Down” and never a false “Up”.
Does it check things behind a login?
Not yet. Today it checks public web addresses and APIs. Multi-step browser checks are planned, and we're asking beta teams which workflow to cover first.