Skip to content

Monitors

Monitors answer different operational questions. Choose the object that matches the failure you need to detect.

MonitorUse it to
HTTP endpointPoll an HTTP or HTTPS URL and validate status codes or response text
CORS baselineDetect changes to expected CORS response headers
DNS delegationValidate A, AAAA, CNAME, NS, or TXT answers against a baseline or rule
User impactPoll journey and metric JSON produced by your application
HeartbeatDetect a scheduled job that stopped sending pings
Single-device offlineDetect loss of connectivity for one critical device
Fleet offlineDetect any offline device, an offline count, or an offline ratio

TCP socket checks, process checks, disk checks, and arbitrary on-device scripts are not current monitor types. Use an HTTP health endpoint, user-impact feed, heartbeat, logs, telemetry, or a fleet job when one of those better represents the outcome.

State and noise control

Device and fleet monitors evaluate on an interval and count consecutive failures. They trigger only after the configured failure count. Recovery has its own consecutive-success count and can use a lower recovery threshold than the trigger threshold. A cooldown prevents repeated notifications while the same condition remains active.

For a ratio monitor, 0.10 means 10 percent. The minimum impacted-device guard must also be met. A fleet of 20 devices with a 10 percent threshold and a minimum of 3 does not trigger when only 2 devices are offline.

Disabling and re-enabling a monitor clears the start of the previous failure period. A newly created monitor may show no result until its first evaluation.

Monitors, alerts, and incidents

  • Device and fleet offline monitors create alerts. They do not directly open incidents.
  • Service, heartbeat, and user-impact signals can feed incident automation.
  • Log alert rules evaluate a supported subset of log search and send webhooks. They are separate from device alert rules.
  • Status pages display selected monitor widgets. Hiding a widget is different from disabling its monitor.

Test changes against a staging target. Confirm both failure and recovery before relying on a route for on-call response.