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
uptime 30d · 6 regions · every 30s
8 check types
HTTP(S) with status and keyword matching, TCP, DNS with record-change detection, SSL with expiry warnings, ping, MTR, traceroute and domain expiry. One product covers the endpoint, the route and the paperwork.
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
Continuous MTR and traceroute detect route changes and path degradation before they become downtime. You see the problem forming, not just the outage after it lands.
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.