Monitors & checks

A monitor is one URL — or one DNS record — 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.

DNS monitors

Your site can answer every check while email bounces because an MX record was deleted, or a certificate fails to renew because a CAA record changed. A DNS monitor watches one record type on one hostname — A, AAAA, CNAME, MX, NS, TXT, SOA, CAA, SRV or PTR — and fails when the name stops resolving or the answer isn't what you expect. For reverse DNS (PTR), enter the IP address.

Expected values — one per line, written like a zone file: 93.184.215.14, 10 mail.example.com (MX — the priority is optional), 0 issue "letsencrypt.org" (CAA) or the TXT text itself. Leave it empty to only require that the name resolves.
Match — Exactly: the answer must be exactly these values, so any record added or removed fails. Includes all: every expected value is present, other records are allowed — the default for TXT, because names like the apex usually hold verification tokens too. Any of: at least one is present, for CDN or load-balanced names that rotate addresses.
Values are compared after normalising case, trailing dots, quotes, IPv6 notation and how a long TXT record is split into strings — MAIL.Example.com. matches mail.example.com.
Public resolvers (default) — asks a validating public resolver (Cloudflare 1.1.1.1, with Google 8.8.8.8 only if it doesn't respond): what your visitors see. You can name a nameserver to ask instead, e.g. your own.
Authoritative nameservers — finds the zone's nameservers and asks every one directly (over IPv4, so IPv6-only nameservers are skipped). Wrong records on any of them fail the check. A hostname that is an alias (CNAME) into another zone works too: every nameserver must return the same alias, and the expected values are checked against the records it leads to.
Degraded — in authoritative mode, when some nameservers don't answer, aren't authoritative or have an address that won't resolve, or when they disagree about records that should be identical everywhere (MX, TXT, NS, CAA, SRV, CNAME, PTR). It's a warning that never opens an incident or counts as downtime. A and AAAA answers can legitimately differ between nameservers (load balancing), and SOA serials often do (providers number them differently), so those differences are shown on the monitor page but never warn.
DNSSEC — lookups also tell whether the zone is signed and valid, shown on the monitor page. When validation fails (expired signatures, a DS record at the registrar that no longer matches), validating resolvers refuse to answer at all, so the monitor goes down with that as the cause.
Change history — when the records a location sees change (seen twice in a row), the change is logged on the monitor page and — if the check still passes — you get a DNS records changed warning (on by default). A change that fails opens an incident instead. Accept a change to make the new records the expected values.

The email preset sets up mail DNS in one go: enter a domain (and any DKIM selectors) and Vigil looks up its MX, SPF, DMARC and DKIM records, then creates one monitor per record with the current values filled in. Records it can't find are reported with advice instead of becoming monitors that would only fail.

DNS records rarely change, so DNS monitors check every 5 minutes by default (any interval from 30 seconds to hourly) with a 5-second timeout. Each lookup reads up to 100 records (16 KB of answers). DNS monitors count towards your plan's monitor limit like any other monitor.

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 — and don't paste it into chat: link previews fetch URLs, and a fetch is a ping. Vigil never includes the ping URL in alerts and refuses fetches from known preview bots and crawlers, but a plain browser visit does count.

Third-party services

Your site can be up while checkout fails because a payment, email or cloud provider is having a bad day. A third-party monitor follows that provider's public status page and turns what it reports into a Vigil status: pick from 100+ services (Stripe, GitHub, Cloudflare, OpenAI, Twilio, Google Cloud, Slack, …) or paste the URL of any status page hosted on Atlassian Statuspage or incident.io.

Components — watch just the parts you use (e.g. GitHub Actions and Webhooks). With none picked, the monitor follows the provider's own overall verdict.
Partial or major outage — opens an incident and alerts like downtime; it resolves when the provider reports the components operational again.
Degraded performance or provider maintenance — shows as Degraded without opening an incident or counting as downtime. Tick the notification option to get a warning when it happens.
Status pages are read every 2 minutes (Refresh now re-reads immediately). If a page can't be read, the monitor keeps its last known status — an unreachable status page says nothing about the service itself.

You're relying on the provider to report its own problems, so alerts are only as quick as their status page. Pair this with an HTTP monitor on your own flow (e.g. checkout) for the full picture. Third-party monitors count towards your plan's monitor limit.

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 locations 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.

Domain expiry

Every HTTP and DNS monitor also watches the registration of the domain it points at — the registered domain, so shop.example.co.uk tracks example.co.uk. There's nothing to set up: Vigil asks the registry over RDAP (or WHOIS, where a registry has no RDAP service), refreshes it regularly, and shows the expiry date, registrar and registry status on the monitor page.

Expiry warning — one alert per expiry date when the domain enters the warning window (default 14 days before expiry, configurable, 0 disables). Renewing moves the date, which arms the next warning.
Lapsed domains — an immediate alert when the registry reports the domain on hold, in its redemption period, pending deletion or no longer registered: states in which it usually stops resolving.
Several monitors on one domain share a single alert per workspace.
IP addresses and hosts on a platform's shared domain (*.github.io, *.vercel.app) have no registration of their own to track. Some registries — several country-code domains among them — don't publish expiry dates; those show registrar and status only.

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). For DNS monitors the snapshot is the lookup: response code, answers and which server replied. 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 (HTTP and DNS monitors); results arrive within ~30 seconds.
Pause — stops checking entirely.
Maintenance — keeps recording checks but never alerts; the status page shows a maintenance banner.