Start here
Quickstart — account to first alert in about five minutes.
Concepts — monitors, checks, thresholds, incidents, and why a failing
monitor sits in pending before it goes down. Ten minutes here saves an hour of confusion
later.
Monitor types
| Type | Answers | Reference |
|---|---|---|
| HTTP | Does this URL respond correctly? | docs |
| TCP | Does this port accept a connection? | docs |
| Heartbeat | Did my cron job run? | docs |
| Certificate | How long until my TLS certificate expires? | docs |
| Domain | How long until my registration expires? | docs |
| DNS | Does this record still say what it should? | docs |
| Email auth | Are SPF and DMARC still published? | docs |
HTTP, TCP and heartbeat run at your chosen interval, from 20 seconds. The other four default to once a day, because certificates and registrations change on a scale of months.
Alerting
Channels — email, webhook, ntfy and Telegram, with setup for each. Includes the Telegram trap that makes a working bot token look broken.
Reminders while still down — repeat the alert while an incident stays open. Off by default.
External second opinion — how WhatPing decides between “the target is down” and “we cannot reach the target”.
Reference
Webhook payload — the full JSON schema, with a real example.
Heartbeat ping endpoint — URL format, methods, responses, and snippets for cron, systemd and GitHub Actions.
Limits and defaults — every bound in one table.
Security model — what is validated, what is redacted, what is stored.
Troubleshooting — the questions people actually ask.
Conventions in these docs
- Every number stated is the value enforced by the product. If a document and the interface disagree, the interface is right and the document is a bug — please report it.
- Alert text shown in examples is the literal text WhatPing sends, emoji included.
- Anything not built is not documented. See the roadmap for what is planned.