Monitors

A monitor combines what to watch, severity and noise, responses, delivery, and escalation. Author it at Alerts → Monitors.

Create and deploy

1. Select New monitor, choose a kind and configure its condition.
2. Choose severity, cooldown and automatic resolution.
3. Add up to ten responses. Responses execute on the device that breached.
4. In Notify, use Inherit, use these channels instead, or inbox only. The inherited preview shows eligible channels, skipped destinations with their reasons, escalation and the winning source.
5. Choose an escalation policy if needed and configure recurrence escalation.
6. Save, test on a device, and attach to a configuration policy. Assign that policy to an organization, site, group or device.

Policy Monitors tabs also offer Attach existing, Create monitor and recommendations for unattached built-ins. Creating a definition alone does not enable policy-based alert evaluation. An enabled network-check definition does provision an active probe before attachment. Definitions retain their organization or partner ownership; incompatible attachments are refused rather than widening access.

Conditions

The kind picker includes resource thresholds, offline state, event logs, patch compliance, service/process state and resources, agent mTLS certificate expiry, bandwidth, disk I/O, network errors, software/security/backup conditions, script probes and network checks. GET /monitor-definitions/kinds returns the exact kinds and supported condition fields on your server.

A few kinds have units or evidence rules worth knowing:

• Bandwidth thresholds are in megabits per second; Disk I/O thresholds are in megabytes per second. Every sample in the duration window must breach.
• Network errors counts the errors that occurred during the window (the increase of each interface’s error counters, with counter resets handled), not the running totals the agent reports. It needs two samples of the interface to evaluate.
• Patch compliance uses the latest hourly posture score. A score older than 24 hours, or one computed for a device with no patch telemetry, counts as no data.
• Certificate expiry watches the Breeze agent’s own mTLS certificate only. It does not inspect certificates installed on the device or served by its services.

Composite monitors contain two to ten server-evaluated child conditions, matching all or any. They cannot nest or contain agent-delivered/worker-provisioned children. Composite conditions do not support per-policy threshold overrides.

Service stopped, Process stopped and Process resource monitors are delivered to the agent directly from the policy’s attached monitors; the per-policy Check interval on the Monitors tab sets how often the agent evaluates them. Their consecutive-failure setting accepts 1–100. A service restart response carries its own maximum attempts (0–50, default 3) and cooldown (30–86400 seconds, default 300). Agent-local restarts continue through the delivered watch configuration. The policy’s Agent collection → Check interval accepts 10–3600 seconds, default 60.

Network check

Kind	Condition	Default severity	Evaluation
Network check	An ICMP, TCP, HTTP or DNS probe run from an agent fails N times in a row (optionally: is degraded or slow)	High	Agent (probe) + server (verdict)

Create network checks here; inspect their history under Network → Results. The optional asset picker binds an organization-owned check to an asset’s site and guides alert-device selection. Evaluation is once per check per organization, even if that alert device is offline; an online agent runs the probe.

Network check fields

Field	Values
Check type and target	ICMP, TCP, HTTP or DNS; IP address, hostname or URL
Asset	Optional asset in the same organization
Type options	Ping count; TCP port/banner; HTTP method, expected status/body, TLS and redirects; DNS record/value/nameserver
Treat degraded as failure	Optional; default false
Fail when slower than	Optional response limit, 1–600,000 ms
Poll interval / timeout	10–86,400 seconds / 1–300 seconds
Consecutive failures	1–100; default 2

The HTTP API field is expectStatus, sent as expectedStatus to the agent. See Network Checks for per-type options, delivery, asset binding, operational probes and retained history.

Inheritance and overrides

Add to inherited monitors is cumulative. A policy contributes its attachments alongside inherited monitors; the resolver chooses the effective attachment for each monitor using assignment scope and priority, including role and OS filters. A closer attachment can disable or override a monitor without editing its definition.

Replace inherited monitors preserves converted inline rules’ replacement behavior. The policy tab shows inherited attachments being ignored. Conversion may set this mode automatically; change it only after reviewing the resulting device coverage. The device Monitoring tab shows the effective result.

Legacy rules

v0.117.0 introduced conversion of legacy alert rules and service/process watches to monitors. From v0.118.0 the API processes remaining sources at startup and retires those that cannot convert with a reason (set BREEZE_LEGACY_ALERTING_SWEEP=false to skip this; leftover rows are then counted and logged at every boot). Alerts → Monitors lists these items in a banner that you can dismiss after review. Source rows and alert history are retained. Open alerts from unconvertible retired rules stay open until someone resolves them; converted sources’ open alerts move to the compiled monitor path.

Conversion history → Undo is no longer available for legacy alert rules, templates, inline policy rules or service/process watches after upgrading to v0.118.0. Review and complete conversion on v0.117.0 before upgrading (see the v0.118.0 upgrade notes). Network checks retain their runtime and are excluded from automatic conversion and retirement.

Converting network checks: use the banner on Network → Results to preview and confirm supported checks, or explicitly retire unwanted ones. Conversion adopts the probe, keeps results and open-alert status/provenance, and attaches the monitor to a cumulative organization-level Network checks — <org name> policy. Non-alerting probes, mixed rules and unsupported predicates or thresholds are refused; a missing runtime prerequisite blocks network preview. Network Conversion history → Undo remains available while that runtime is retained. See conversion details.

The retired legacy write endpoints, including POST /alerts/rules/:id/test, return 410 Gone; historical reads remain available. Test monitors with POST /monitor-definitions/:id/test.

Built-in alerts

Breeze raises some alerts itself rather than through a monitor: Patch job failures, Reboot pending too long, and policy-violation alerts. Each rule belongs to one organization (policy violations get one per policy), is created the first time its alert fires, and is never offered for conversion. Alerts → Monitors lists them under Built-in alerts with an Active switch per organization. Switching one off stops new alerts of that kind for that organization and stays off; alerts that are already open stay open until you resolve them. The switch needs alerts:write and MFA, and is recorded in the audit log as alert_rule.update. Through the API, send PATCH /alerts/rules/:id/active with { "isActive": false }. Any other legacy rule returns 410 Gone.

Device Monitoring and recurrence

Open a device’s Monitoring tab (#monitoring) to see effective monitor, kind, source policy, healthy/breaching/unknown state, open episode and escalation status. No evidence means unknown. Disabled winning attachments remain visible.

Recurrence counts breach episodes rather than repeated samples of one continuous breach. When escalation pauses responses, Reset escalation clears the latch and resumes responses. Reset does not close the open episode or resolve its alert. The server enforces alert-write permission and MFA for the reset action.

Automation and AI tools

Use Jobs → Alert workflows for broad event-triggered behavior. Severity and kind filters are optional; monitor responses stay device-bound. Fleet Designer proposes monitor definitions and applies them as policy attachments. Historical proposals using the old rule shape must be regenerated before applying.

manage_monitor_definitions authors monitors. Attach through manage_policy_feature_link with featureType: "monitors". manage_service_monitors lists effective service/process monitors only.

API and troubleshooting

Monitor CRUD, attachments, device tests and activity live under /monitor-definitions. Conversion routes live under /monitor-definitions/conversion. The device view reads /devices/:id/monitors; escalation reset posts to /monitor-definitions/:id/devices/:deviceId/reset.

If a monitor does not appear on a device, check policy assignment, role/OS filters, inheritance and enabled state. If notifications are missing, inspect the resolved delivery preview and Delivery. If a response is paused, inspect recurrence escalation before resetting it. Compiler-managed rows are implementation details; change the monitor definition rather than editing them.

The Monitors page shows N legacy rules could not be converted. Open the list; each row names the policy and the reason. Recreate the condition as a monitor (Composite for multi-condition rules), then dismiss the banner.