Monitors

Monitors

A monitor watches a page and tells you when it changes. Two kinds:

Content	Watches a CSS selector and reports when the text inside it changes.
Uptime	Watches availability and response, and tracks SSL-certificate expiry.

Creating one

Monitors → New. Give it a URL, choose the type, and for a content check supply a selector — or pick the element visually.

Set the cadence as an interval or a daily/weekly wall-clock time. The detail pane shows time since the last check and counts down to the next one.

What it records

• Change history — what changed and when
• Uptime history and response behaviour
• SSL expiry, so a certificate does not lapse unnoticed

Records are purged after DETECTED_CHANGE_RETENTION_DAYS (default 90).

Acting on a change

A monitor can fire a workflow the moment it trips — set the on-change workflow in the monitor's settings. That is the usual way to build "when this page changes, go and collect the details".

For anything richer — notify a channel, POST a webhook, chain several workflows — see Automations.

Quorum

QUORUM (default 2) is how many agents must agree before a change is confirmed. It exists because a single agent can see a transient — a partial render, an A/B variant, a CDN blip — and report a change that is not real. With one agent connected there is nothing to cross-check, so raise the count once you run several.

Engine

Content checks use a plain HTTP fetch where that is sufficient, and a real browser when the page needs rendering. The detail pane shows which engine a monitor is using.

Notes

• Monitors need a connected agent, like everything else.
• Targets resolving to private or loopback addresses are refused unless ALLOW_PRIVATE_TARGETS=true. That is the SSRF guard — see Security model.
• Per-host dispatch is rate-limited by TARGET_DOMAIN_RATE_LIMIT.