Platform
Monitoring that sees the whole path — not just the endpoint
Monitors
- api.acme.com HTTP 82 ms
- acme.com HTTPS 104 ms
- db-primary (probe) TCP 3 ms
- mail.acme.com SSL expires in 74 days
- cdn edge — GRU MTR loss 2.1%
- legacy.acme.com PING timeout
illustrative data · public and private probes
15 monitor types
HTTP(S), TCP, DNS, SSL, ping, MTR, traceroute, domain expiry, SPF, DKIM, DMARC, MX, RBL, SMTP and DNS Watch. One product covers availability, route evidence and domain/e-mail health.
Multi-region by default
Every monitor runs from multiple probes. A regional problem shows up as a regional problem — not as a false "up" reported by the one server that happens to have a clean route.
Route-aware
Scheduled MTR and traceroute checks record route and packet-loss evidence. DNS Watch records drift against its captured baseline, so the result shows what changed instead of only up or down.
How a monitor is configured
A monitor is a target plus regions plus rules. Automations react to state changes:
monitor:
type: http
target: https://api.example.com/health
regions: [us-east, eu-west, sa-east]
frequency: 60s
automation:
when: monitor goes down
then:
- POST https://hooks.example.com/alert # webhook
- open incident on status page Questions
FAQ
What is the minimum check frequency per plan?
Free checks every 5 minutes, Pro every 60 seconds, Business and Enterprise every 30 seconds.
What's the difference between a ping and an HTTP check?
Ping proves the machine answers ICMP; the HTTP check proves the application answers real requests with the status you expect. A healthy ping with a failing HTTP check means the server is up and the app is not.
What is DNS record-change detection?
The DNS monitor stores the answers it sees and alerts when they change — catching hijacks, botched migrations and expired delegations that a simple uptime check never notices.