Vigil

Monitors & checks

A monitor is one URL checked on a schedule from the monitoring network. Everything below is configured per monitor.

Basics

  • Interval — from every 30 seconds to hourly. Default: every minute.
  • Timeout — how long a check may take before it counts as failed (default 10s).
  • Expected status — a class like 2xx/3xx or an exact code like 200.
  • Body keyword — optionally require the response body to contain (or not contain) a snippet of text, case-insensitive. Catches pages that return 200 but render an error.
  • Redirects — followed by default (up to 10, browser semantics); the final destination is shown per location, and you can be alerted when it changes.
  • Checked from — pick which locations check this monitor; selecting all (or none) means every location, including ones added later.

API monitoring

Monitors support GET, HEAD, POST, PUT, PATCH and DELETE. Under Request options you can set:

  • Custom headers — one per line, e.g. Authorization: Bearer … or X-Api-Key: …
  • Request body — JSON, form-urlencoded or raw text (body-capable methods only).
  • HTTP Basic auth — username/password for protected endpoints; the Authorization header is built automatically.

Heartbeat monitors

Heartbeats invert the direction: instead of Vigil checking your URL, your cron job, backup script or queue worker pings a unique Vigil URL after every successful run — e.g. curl -fsS <ping url> as the last line of the script. When no ping arrives within the expected interval plus a grace period, an incident opens and the normal alert flow kicks in; the next ping resolves it. Keep the ping URL secret — it's the only authentication.

Verification: confirmations and quorum

Confirmations (default 2) is how many consecutive failures a single location must see before that location counts as down. Quorum (default 1) is how many locations must be down before an incident opens. Raise the quorum to 2+ to require independent regions to agree before anyone is woken up.

SSL certificates

For https monitors, certificates are inspected about once an hour. The monitor page shows issuer, expiry date and days remaining, and you get one alert per certificate when it enters the warning window (default 14 days before expiry, configurable, 0 disables). Certificate validation failures (expired, wrong hostname, self-signed) fail the check itself and follow the normal incident flow.

Failure diagnostics

When a check fails, the probe captures the response headers and the first 4 KB of the body. The moment downtime is confirmed, that snapshot is frozen onto the incident — open any incident in the dashboard to see exactly what the probe saw (HTTP status, server headers, the error page itself). Snapshots are internal only and never appear on public status pages.

Bot-protection challenges

When a check receives a challenge page (Cloudflare "Just a moment…" and similar) instead of your site, the monitor shows Challenged: it is not counted as downtime, never opens an incident, and uptime numbers are unaffected. You can opt into a warning notification when it happens.

Check Now, pause and maintenance

  • Check now — queues an immediate re-check; results arrive within ~30 seconds.
  • Pause — stops checking entirely.
  • Maintenance — keeps recording checks but never alerts; the status page shows a maintenance banner.