Skip to main content
Monitors are experimental. The API, CLI and storage may change between releases.
A monitor probes an endpoint on a schedule from the control plane and records the result. This first slice has http and tcp monitors, a result history, and hourly rollups. It does not send alerts, open incidents or change the status page. The feature is off by default. When APP_MONITORS_ENABLED is not true, the /api/v1/monitors routes answer 404 and no scheduler runs.

​
Kinds

  • http: method (GET, HEAD, POST, PUT), optional headers, accepted status codes or ranges (default 200 to 399), an optional contains keyword searched in the first bytes of the body, and a timeout. Redirects are not followed unless asked for, up to a server limit.
  • tcp: a host and port. The check passes when the connection completes within the timeout.
Header values are stored encrypted with the same secret store as app secrets. They are never returned by the API or the CLI, and results keep only a short failure class such as timeout or status_mismatch, never a body or header value.

​
Network safety

Every connection, including redirects, goes through the outbound address guard. Private, loopback and link local addresses are refused unless the control plane has explicitly allowed private outbound targets. A refused target shows as blocked_address and is rejected at create time.

​
Results

Results are written in batches, with the hourly rollup updated in the same transaction. Raw results are kept for a short window and rollups for much longer. Pruning runs in small batches so it does not hold the database write lock.

​
Settings

All limits are environment variables on the control plane. Durations use Go syntax such as 30s or 48h.

​
API

  • GET /api/v1/monitors, POST /api/v1/monitors, DELETE /api/v1/monitors/{id}
  • GET /api/v1/monitors/{id}/results?window=24h&limit=100 returns recent raw results and hourly rollups.
Reading needs read access and changing needs write access on the monitors resource. Creating and deleting are recorded in the audit log.
Last modified on October 30, 2026