Docs/Monitors
Monitors
Five protocols, one incident pipeline. Pick the type that matches what you're checking; everything else (intervals, regions, alerts) is the same across types.
| Type | Watches |
|---|---|
| HTTP / HTTPS | Status code, response body, headers, latency |
| TCP | Connect succeeds on host:port |
| UDP | Send a payload, expect a response |
| SSL | TLS certificate validity and days-to-expiry |
| DNS | Record value matches expected IPs / strings |
Common settings
Every monitor has these regardless of type.
- Interval — how often to run the check. Defaults to 60s. Minimum is plan-dependent (see Plans). Lighthouse monitors can go as low as 5s.
- Timeout — how long a single attempt may run before being marked failed. Defaults to 30s.
- Regions — one or more public probes; each region runs its own schedule. See Regions. Lighthouse monitors run from your agent and ignore this.
- Pause — Lighthouse monitors can be paused via the agent config flag. Public monitors are always running once created.
Failure semantics
A single failed check opens an incident. A single successful check resolves it. There's no "N consecutive failures" threshold for public monitors. Lighthouse agents support a per-agent flap-protection threshold that requires N consecutive same-state results before a transition.
Recovery fires its own notification; downtime is recorded against the 24h / 7d / 30d uptime metrics for the monitor.
Uptime
Each monitor displays three rolling-window uptime percentages: 24h, 7d, 30d. They're computed from resolved-incident downtime within each window — not from raw check results — and recalculate when an incident resolves rather than on every check, so they don't flicker as data arrives.
The status page also renders a 90-day daily timeline (one bar per day) sourced from a separate daily aggregation. See Status page for the details.
Paused monitors are excluded from uptime calculations — pausing a monitor freezes its numbers until you unpause.
HTTP / HTTPS
The most common monitor. Watches a URL and asserts on the response.
| Field | Default | Notes |
|---|---|---|
| URL | — | https://... or http://... |
| Method | GET | GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS |
| Expected status code | 200 | Single value; ranges aren't supported |
| Keyword check | none | Substring that must appear (or not appear, via the toggle) in the response body |
| Request headers | none | See Request headers |
| Expected response headers | none | See Expected response headers |
| Request body | none | Used with POST / PUT / PATCH |
| Skip TLS verify | off | Disable cert validation; useful for staging |
| Timeout | 30s | Per attempt |
The check follows redirects and asserts on the final response. Both request and expected response headers apply across the redirect chain.
Failure causes you'll see: status mismatch, keyword mismatch, header mismatch, timeout, TLS handshake error, DNS resolution failure, connection refused.
Request headers
Send custom headers on every check. Useful for monitoring authed
endpoints (Authorization: Bearer ...), private API surfaces
(X-Api-Key), or asserting on tenant-specific behavior
(X-Tenant-Id).
| Limit | Value |
|---|---|
| Max headers | 20 |
| Max value length | 4 KB |
| Reserved (cannot be set) | Host, Content-Length, Connection, Transfer-Encoding |
Header names are case-insensitive — Host, HOST and host are
all rejected.
Expected response headers
Assert on headers in the response. Each entry has a key and a match mode:
| Mode | Pass condition |
|---|---|
present | The header is set, value ignored |
exact | The header is set and its value equals yours |
contains | The header is set and its value contains your substring |
Same per-monitor caps as request headers (20 max, 4KB per value). A single mismatch fails the check with a clear message naming the header.
TCP
Opens a TCP connection and closes it. Use for databases, brokers, custom services that don't speak HTTP.
| Field | Default | Notes |
|---|---|---|
| Host:port | — | db.internal:5432, redis.svc:6379 |
| Timeout | 30s | Connect timeout |
The check passes if the TCP handshake completes. It does not send any payload or read a banner.
UDP
Sends a payload, optionally waits for a response.
| Field | Default | Notes |
|---|---|---|
| Host | — | Hostname or IP |
| Port | — | UDP port |
| Send payload | — | Bytes to send (typically a protocol-specific probe) |
| Expected response | none | If set, the response must equal this exactly |
| Timeout | 30s | Total round-trip |
Useful for: DNS resolvers (with a crafted query), game servers, NTP, custom UDP services.
SSL
Watches TLS certificate health on any HTTPS endpoint.
| Field | Default | Notes |
|---|---|---|
| URL | — | https://example.com — the domain is extracted |
| Days warning | 14 | Open an incident this many days before expiry |
| Timeout | 30s | TLS handshake timeout |
The monitor fails on: certificate expired, hostname mismatch, broken
chain, or fewer than days_warning days remaining.
DNS
Resolves a record and (optionally) asserts on the values returned.
| Field | Default | Notes |
|---|---|---|
| Hostname | — | The name to resolve |
| Record type | A | A, AAAA, CNAME, MX, TXT, NS |
| Expected values | none | One or more strings; all must appear in the answer |
| Timeout | 30s | Resolution timeout |
DNS monitors run from a single location regardless of the regions you select — comparing DNS results across regions is a separate feature on the roadmap.
Plan-gated types
Free includes HTTP, TCP and UDP monitors. SSL and DNS unlock on Pro. See Plans & limits for the full matrix.