Add your URLs. Watchline checks them on a schedule, alerts you on confirmed outages — two consecutive failed checks, so a single blip never pages you — and publishes a public status page your customers can watch while you fix it.
Every confirmed state change is recorded with timestamps and detail, and served in the status payload — the same timeline your customers read on the public page, and a real audit trail for you.
Checkout API: two consecutive failed checks — expected status 200, got 502. State persisted; incident opened.
Cause posted to the public timeline in plain language, with the time of the next update.
Fix deployed. The monitor stays in the incident until the checks prove it is back.
Two consecutive successes close the incident. Duration and detail stay in the history.
Each monitor checks an http(s) URL against expected status codes, with an optional keyword that must appear in the response body. Intervals from 10 seconds up, per-monitor timeouts.
A monitor is DOWN after 2 consecutive failures and UP after 2 consecutive successes. State persists to disk across restarts.
Every confirmed state change is recorded with timestamps and detail, and served in the status payload — a real audit trail.
Webhooks (JSON POST, 3 retries with backoff), email via the Resend API, and SMS via Twilio's Messages API. Every dispatch returns a per-channel report: sent, failed, not_configured, or misconfigured — never silent.
The service renders a real public status page from live data — overall banner state, per-monitor uptime and latency, 90-day uptime bars, and the incident timeline. GET /status serves the same data as JSON: summary counts, per-monitor detail, and the 20 most recent incidents.
