Uptime · certificates · domains · DNS · email auth
The outage that returns HTTP 200 right up until it doesn’t
Your certificate expires. Your domain registration lapses. Someone edits a DNS record. Your SPF breaks and your email stops arriving. A health check sees none of it — and then everything is down at once. WhatPing watches all four, alongside ordinary HTTP, TCP and cron monitoring.
Free while in beta · no card · 20 monitors per workspace · one probe location
check history← certificate expired here
01 — The gap
Four outages your health check will never predict
Your domain expires on a Sunday
The registrar pulls the nameservers, the zone stops resolving, and every service on the domain disappears at once. Email included, so you may not even get told.
A health check would have returned 200 the whole time.
Not down. Worse than down.
Browsers show an interstitial, API clients throw TLS errors, mobile apps fail silently. The server is fine, and it will keep telling you so.
A health check would have returned 200 the whole time.
Your mail starts landing in spam
Including the alert emails that were supposed to tell you something is wrong. The monitoring is up. The path from the monitoring to you is not.
A health check would have returned 200 the whole time.
Every one of these is a total outage with no warning signal in the place everyone looks. So WhatPing looks somewhere else as well.
02 — Monitor types
Seven things worth watching
Status ranges, redirects, and a keyword assertion for when 200 is a lie
TCPA port either accepts a connection or it doesn't
HeartbeatYour cron job pings on success; we alert when it stops
CertificateDays until your TLS certificate expires, checked daily
DomainDays until your registration expires, read from the registry
DNSAssert an A, AAAA, MX, TXT, CNAME or NS record still says what it should
Email authSPF and DMARC present and valid, so your mail keeps arriving
03 — Alerting
Alerts that keep working when the first one doesn’t
Email, webhook, ntfy and Telegram. The webhook payload carriestext and content aliases, so one endpoint works for Slack, Discord, Mattermost and plain automation receivers without per-provider setup.
Reminders while you are still down. Most tools alert once, on the transition. If that message fails to deliver, a six-hour outage is indistinguishable from everything being fine. Off unless you turn it on — a repeating alert on a flapping monitor is how people learn to filter your notifications.
A second opinion. When a check fails, WhatPing asks a network that isn’t ours whether it agrees, and says so in the alert. “The site is down” and “we can’t reach the site” are different problems.
🔴 DOWN — api (https://api.example.com):
connect failed: Connection refused (os error 111)
🔴 STILL DOWN (1h 35m) — api (https://api.example.com):
connect failed: Connection refused (os error 111)
· confirmed unreachable from a second network
🟢 RECOVERED — api (https://api.example.com) after 5820s04 — How it works
Three moving parts
- 01A stateless Rust prober runs the checks. It holds no state of its own, so it can be restarted mid-outage without losing or duplicating anything.
- 02A backend that owns every decision. The prober reports raw observations; whether that means “down” is decided in one place, against your threshold.
- 03Certificate, domain, DNS and email checks run daily, because a certificate does not stop being valid between one minute and the next.
05 — Proof
No testimonials. Here is what you can check instead.
It monitors its own prober
A heartbeat monitor watches the probe worker, so if the worker dies the system tells you rather than going quiet. Not theoretical — it caught a parsing bug that froze the worker on a stale configuration, and it was the only signal anything was wrong.
A broken alert channel cannot corrupt your monitoring
Delivery is attempted after state is already committed, and every attempt is recorded. A webhook returning 500 forever will never make a monitor look up or down.
A retry cannot double-page you
Every check result carries a producer-generated ID, so a replay after a network blip is discarded rather than opening a second incident.
Start with the one you keep forgetting
Add a domain expiry monitor. It takes about thirty seconds, it costs nothing, and it covers the failure that no amount of health checking will ever warn you about.