Skip to content
Pingwell

Everything between “it's down” and “it's fixed”.

Uptime monitoring

HTTP checks with the status codes you expect and a keyword that must, or must not, appear; TCP checks for databases and anything else with a port. Checks run from up to 8 regions, as often as every 30 seconds.

A failure is checked again from up to two more regions, and the monitor goes down only when at least two regions, and at least half of those that answered, agree. A single bad route stays a blip, not an incident.

Heartbeats

Give a cron job, a worker or a backup script its own URL. It pings when it starts and when it finishes, or reports a failure with its exit code and output. If the ping doesn't arrive inside the period and grace you set, you hear about it.

The ping API

Status pages

Give each component a monitor or heartbeat to follow, or a status you set by hand. Post incidents and scheduled maintenance as they happen. Put the page on your own domain, or behind a password for an internal audience, on Pro and Unlimited.

Pages are published to the edge, so they stay up when your own servers don't.

Alerting

Choose per monitor which channels hear about it: down, degraded, late and recovered. Degraded and late wait a moment first, so a blip that clears itself never pages anyone. Failed deliveries are retried, and every attempt is on the channel's page.

The webhook payload

Try it on your own stack.

Start free