WatchTower sends HTTP requests to your endpoints on a schedule. If a monitor's status code doesn't match what you expect for a configurable number of consecutive checks, it opens an incident and notifies you. When the endpoint starts responding again, it resolves automatically.
How it works
1Check execution
GET https://api.example.com/health
→ 200 OK (12ms)
→ body contains "healthy"
→ check passed
GET https://staging.example.com
→ 503 Service Unavailable
→ expected 200, got 503
→ consecutive failures: 2 of 3Sends an HTTP request at your configured interval. Validates the status code and optionally checks for a keyword in the response body.
2Failure detection
UP
──[check fails]──→ failures: 1/3
──[check fails]──→ failures: 2/3
──[check fails]──→ failures: 3/3 → DOWN
├ open incident
└ dispatch alerts
DOWN
──[check passes]──→ UP
├ resolve incident
└ send recoveryA monitor transitions to DOWN only after the failure threshold is met across consecutive check intervals. Default is 3. Configurable per monitor. One passing check resolves the incident.
3Alert channels
Monitor name, URL, status, error, timestamp.
Slack
Incoming webhook. Posts to your channel.
Webhook
POST JSON with HMAC-SHA256 signature. Route to PagerDuty, Opsgenie, or your own handler.
4Uptime badge
Public SVG endpoint with 60-second edge cache. Embed in your README, docs, or status page. Color scales with uptime: green > 99.9%, amber > 99%, red below.
Specs
Pricing
| Free — $0 | Starter — $5/mo | |
|---|---|---|
| Monitors | 10 | 50 |
| Interval | 5 min | 1 min |
| Alerts | Email, Slack, webhook | |
| Retention | 7 days | 30 days |
| Badge | Yes | Yes |
| Card required | No | Yes |