Most monitoring answers one question: is the server responding? That question matters, and WhatPing answers it — from 20-second intervals, with status ranges, redirect following and keyword assertions.
But it is not the question that causes most of the outages that surprise people. Those come from things with expiry dates and things that get edited: certificates, registrations, DNS records, SPF. WhatPing watches those on the same schedule, in the same dashboard, through the same alert channels.
Liveness
Is it up right now?
HTTP monitoring
Accepted status expressions like 200-299,301, so a 204 API or a redirecting site is
monitorable. Redirect depth you control. Keyword assertions, including inverted ones, to catch
the case where the server returns 200 and serves a broken page.
TCP monitoring For everything that isn’t HTTP: a database port, an SMTP listener, a game server. Either the port accepts a connection or it doesn’t.
Heartbeat monitoring Inverted monitoring for things that have no address to poll. Your cron job, backup script or CI pipeline requests a URL when it succeeds; WhatPing alerts when the request stops arriving. A backup that silently stopped running two weeks ago is the classic case.
Expiry and drift
Will it still be up next month?
Certificate monitoring Days remaining on your TLS certificate, checked daily, with a threshold you set. The default warns at 30 days, which is enough time for a renewal to be routine rather than an incident.
Domain expiry monitoring Read from the domain registry, not inferred from DNS. An expired registration takes down every service on the domain at once, and there is no health check anywhere that predicts it.
DNS monitoring Assert that a record still contains what it should. A, AAAA, MX, TXT, CNAME and NS. Catches a fat-fingered edit, a failed migration, or a record that quietly went missing.
Email authentication monitoring SPF and DMARC, checked daily. This is the one nobody else in this category does, and it protects the path your alerts travel down.
Alerting
Getting told, reliably
- Four channels — email, webhook, ntfy, Telegram. The webhook shape works with Slack, Discord and Mattermost as-is.
- Reminders while still down — because one alert that fails to deliver is a missed outage. Off by default.
- A second opinion — WhatPing asks an independent network whether it agrees the target is unreachable, and labels the incident with the answer.
- A delivery ledger — every send is recorded, so a channel that has been quietly failing is visible rather than assumed to be working.
What WhatPing does not do
Stated plainly, because finding out later is worse.
- One probe location. Checks run from a single network. The second opinion gives you one independent confirmation, not a global probe fleet.
- No status pages. Designed, not built — see the roadmap.
- No maintenance windows, incident acknowledgement, or on-call scheduling. Also on the roadmap.
- No SMS or phone calls. Email, webhook, ntfy and Telegram only.
- 20 monitors per workspace, and 7 days of raw check history.
If you need multi-region probing and on-call rotation today, Better Stack does that and WhatPing does not.