Monitoring

Monitor types, configuration, execution, state, and diagnostics.

Monitors define targets, check locations, pass criteria, and incident thresholds. Open Monitors to create, filter, inspect, clone, pause, export, or delete monitors.

Monitor typesCopy link

Heartbeat URLs and other stored request secrets are revealed only where a workflow creates or rotates them. Store one-time values immediately. See Monitor credential security.

Create and classify a monitorCopy link

Select Add monitor, choose a type, and fill in its target. The editor is organized into four tabs: Organization, Checks, Lifecycle, and Network.

The Lifecycle tab applies to every type:

• Check frequency: how often Status runs the check, from 30 seconds to 86,400 seconds (default 60 seconds). For heartbeats this is the expected push cadence.
• Confirmation period: how long a failure must persist before the monitor is marked down and an automatic incident opens (default 60 seconds).
• Recovery: how long healthy checks must persist before a down monitor returns up and its automatic incident resolves (default 60 seconds).
• Response-time threshold: marks a successful check failed when it is slower than this many milliseconds. Zero disables the threshold.
• Retries after failure: up to five retries before reporting the check down, with a fixed or exponential delay between attempts.

The Network tab chooses where and how checks run:

• IP protocol: automatic, IPv4 only, IPv6 only, or dual stack.
• Timeout: aborts a check that runs longer than this (1,000–30,000 ms).
• Worker regions: comma-separated region IDs; empty runs on every worker.
• Regional success policy: whether all, a majority, or any selected region must pass.
• Private agents: restricts the check to specific registered agents.
• Dependencies: suppress this monitor's failures while an upstream dependency is down.

Classification fields on the Organization tab make the monitor useful beyond the checks themselves:

• tags, folder, and environment drive list filters, grouping, and rules;
• description, tier, and lifecycle explain operational importance;
• owning team connects response ownership;
• runbook, repository, and dashboard URLs put responder tools next to health.

The list combines text, state, tag, folder, and environment filters. The sidebar environment selector applies the same environment scope throughout the console. Named templates and recipes avoid repeating configuration; import, export, and clone preserve the typed settings. See Monitor templates and Monitor transfer. Catalog rename/delete behavior and ownership metadata are covered in Monitor taxonomy and ownership.

Choose where checks runCopy link

Shared workers serve the deployment. A monitor may run in selected regions and use an all, majority, or any aggregation policy. Status waits for a fresh result from every selected region before changing state; a tied majority also waits. Automatic, IPv4-only, IPv6-only, and dual-stack modes control address-family execution. Dual-stack health changes wait for both family observations. See IPv4 and IPv6 monitoring.

Assign private agents when a target is reachable only from particular networks. See Monitoring agents.

Monitor statesCopy link

• A monitor with no decisive result yet shows Waiting (the status filter calls this state pending). A new heartbeat remains waiting through its first deadline.
• Operational and down reflect confirmed, aggregated observations.
• Paused is the manual master switch and stops scheduled execution.
• A schedule can enable or disable checks at local one-time, daily, or weekly windows. Disable wins if windows overlap, and a schedule cannot override a manual pause.
• Maintenance suppresses execution and prevents late results from changing state or opening/resolving incidents.
• If an upstream dependency is unhealthy, downstream failures remain in history but do not change health or create cascading incidents. The list shows this as Dependency suppressed.

Failure confirmation delays noisy transitions; recovery confirmation prevents brief success from closing an incident. Automatic incident behavior is detailed in Incidents, schedules in Monitor schedules, and maintenance in Maintenance.

Test and diagnoseCopy link

Use Test configuration in the editor to run a draft, or Run now on a saved monitor. A workbench run executes the configuration without changing the saved monitor or its production health. Runs are asynchronous and can be cancelled. The result drawer shows attempt/retry counts and total timing. When the worker supplies diagnostics it can also show:

• resolved addresses and DNS/connect/TLS/TTFB/transfer phase timing;
• assertion expected and actual values;
• redirect hops and a bounded response sample;
• certificate subject, issuer, validity, fingerprint, and alternative names;
• API-sequence step status, extracted variables, and cleanup steps;
• bounded traceroute information when available.

Sensitive request material is excluded from displayed results. An empty diagnostics section is not itself a failed check. See Monitor workbench.

Manage existing monitorsCopy link

Row actions provide Inspect, Edit configuration, Configuration history, Result history, Pause or Resume checks, Clone monitor, Copy target, and Delete monitor. Multi-select supports bulk enable, pause, classification replacement, and deletion. Deleted monitors remain restorable for 30 days in the Recycle bin. Configuration history excludes routine health churn; restoring a snapshot creates a new audited version rather than erasing later history.

Related documentationCopy link

• Analytics turns result history into availability and latency reports.
• Alerting routes incident events to external destinations.
• Run monitor workers documents the worker deployment and its check semantics.
• Deployment events correlates releases with monitor and incident health.