Service & Process Monitoring

Overview

Service monitoring has two sides. You define what an agent should watch inside the Monitoring feature of a configuration policy, and you read the results on each device’s Monitoring tab. The agent evaluates the policy on a fixed interval, reports the status of every watched service and process, and can restart one that stops.

A Monitoring feature covers one thing: service & process watches — services and processes that must keep running, with optional auto-restart. Event log alerts and metric/offline alert rules live in the Alerts feature of the policy instead — see Alerts vs. Monitoring for the boundary between the two, and Alerts for how to configure them.

Note

Metric alert rules and event log alerts used to be configured here. They were automatically moved to the Alerts feature of the same policy during the 2026-07-30 alerts/monitoring consolidation — no rules were lost, but you now edit them on the Alert Rules tab instead of Monitoring.

Because Monitoring is a configuration-policy feature, it can be owned by a single organization or made partner-wide to apply the same watches across every organization you manage. See Configuration Policies for how ownership and the cascade work.

Define monitors in a configuration policy

1. Open the policy’s Monitoring tab. In a configuration policy, select the Monitoring feature. Set the Check interval (how often the agent re-checks watches, 10–3600 seconds, default 60).

2. Add a service or process watch. Choose the watch Type (service or process) and enter the Name — the service key (e.g. Spooler, sshd) or process name (e.g. node). The name field autocompletes from services previously reported by your fleet. Optionally set a friendly Display name.

3. Configure the alert behavior. Pick an Alert severity (critical, high, medium, low, info), toggle Alert on stop, and set Consecutive failures (1–100, default 2) before an alert fires. For process watches you can also set a CPU threshold (%), Memory threshold (MB), and a Threshold duration (seconds) the breach must persist.

4. Optionally enable auto-restart. Turn on Auto-restart to have the agent restart a stopped watch. Set Max restart attempts (0–50, default 3) and a Cooldown (seconds, default 300) between attempts.

5. Save the feature. The watches are stored on the policy and delivered to every device the policy resolves to.

Need to alert on an event log entry, or a CPU/RAM/disk threshold, instead of (or in addition to) watching a service? Add an Alert Rules feature to the same policy — see Creating Alert Rules. One policy can carry both a Monitoring feature and an Alert Rules feature at once.

Tip

You can also manage watches programmatically through the AI/MCP tools manage_service_monitors and get_service_monitoring_status.

Note

Auto-restart and process CPU/memory thresholds are the most common cause of unexpected alerts. Start with Alert on stop only, confirm the watch reports cleanly on a device, then layer in thresholds and restarts.

See results on a device

Open a device, then select the Monitoring tab (#monitoring). Breeze loads the latest per-watch summary reported by that device’s agent and shows one row per watched service or process:

Column	Meaning
Name	The service key or process name being watched.
Type	service or process.
Status	running, stopped, not_found, or error.
CPU	Most recent CPU usage for the watch (process watches).
Memory	Most recent memory use in MB.
PID	Process ID, when running.
Last checked	Timestamp of the most recent agent report, in your timezone.

Watches that are not running are sorted to the top so problems are visible first. If the policy enabled auto-restart, a row shows an Auto-restarted or Restart failed badge next to its status. Use Refresh to re-fetch the latest summary.

Note

The device tab reflects what the agent last reported for that device — it is read-only. To change what is watched, edit the Monitoring feature on the configuration policy assigned to the device.

Troubleshooting

A device shows no monitoring rows

The device has no watches assigned, or the agent has not reported yet. Confirm a configuration policy with a Monitoring feature resolves to the device, then wait for the next check interval and press Refresh.

A watch stays not_found

not_found means the service key or process name doesn’t exist on that device. Verify the exact name (Windows service keys are case-sensitive and differ from display names) and that the target OS actually runs that service.

Auto-restart isn’t recovering a service

Check that Auto-restart is enabled on the watch and that Max restart attempts hasn’t been exhausted within the Cooldown window. A Restart failed badge means the agent attempted a restart but the service did not come back.

A watch alert isn’t firing

Confirm Alert on stop is on and the Consecutive failures count has been reached. See Alerts for where triggered alerts appear.

An event-log or metric alert isn’t firing

Event log alerts and metric/offline alert rules are configured and evaluated as part of the Alert Rules feature, not Monitoring. Check the category, minimum level, count threshold, and time window on the Alert Rules tab of the policy — see Creating Alert Rules.

Partner-wide policy edits are greyed out

Partner-wide Monitoring policies can only be edited by partner-level users with access to every organization. Organization-scoped users see the inherited settings but cannot change them — see Configuration Policies.

Related

• Configuration Policies
• Alerts
• Network Monitors
• Devices