Monitoring and alerts
How devices report, how alert rules and monitors raise alerts, maintenance mode, and how alerts become tickets in your PSA.
Updated
Devices running RevoAgent 0.10 or later send a short performance sample every minute: processor and memory use, free space on each disk, network throughput and the busiest processes. Open a device to see its latest sample under Monitoring. From RevoAgent 0.11, devices also run the monitors their policy gives them (services, processes, event logs, ping, ports and websites) and report the results.
Monitoring (in the RMM group of the sidebar) lists the alerts those samples and monitors raise. It needs RevoRMM on for the customer. What raises an alert is set in Policies.
Alert rules
Four rules are built in and apply everywhere until a policy changes them:
| Rule | Opens when | Default |
|---|---|---|
| CPU busy | Above the threshold for the whole duration | Above 95% for 15 minutes, medium |
| Memory nearly full | Above the threshold for the whole duration | Above 95% for 15 minutes, medium |
| Disk space low | Any disk's free space below the threshold | Below 10% free, high |
| Device offline | No check-in for longer than the threshold | 30 minutes, high |
A policy can change a rule's threshold, duration and severity, switch it off, or set a re-arm time: after an alert resolves, a new one for the same device and rule waits that long. A device that was already silent for more than a week when monitoring first saw it gets no offline alert: it's long gone rather than an incident, and the device list shows it as stale.
Monitors
A failing monitor opens an alert named after it ("Print spooler on FRONT-DESK: stopped"):
- Service, process, ping, TCP port, website and script monitors open an alert once the check has failed for the monitor's failing for minutes, and resolve it when the check passes again.
- Event log and system journal monitors open an alert when new matching events arrive, add later events to the same alert, and resolve it after the monitor's quiet time without new ones.
A check that couldn't run (no permission, a log that doesn't exist) shows as a check error on the device and opens nothing. An alert whose monitor is taken out of the device's policy resolves within a minute.
Working alerts
Acknowledge tells the team someone is on it; Resolve closes it by hand (it opens again if the problem is still there at the next result). Resolved shows closed alerts. Click an alert for its details: the reading or the check's message, the latest matching events, what a monitor tried to fix (start a service, end a process), its policy and its ticket.
Alerts opening and resolving are events your automations and webhooks can use. Notifications about them are off unless you turn them on (Settings → Notifications); critical ones reach the workspace's alert recipients.
Maintenance mode
Planned work makes noise: a server restarting for updates goes offline, a disk swap throws disk errors. Put the device, a site or the whole customer in maintenance mode first, for 5 minutes to 7 days, with a reason:
- on the Monitoring page, Maintenance mode (pick the customer);
- on a device's Monitoring tab, Maintenance mode.
While it lasts, alerts are recorded under Muted but not opened, announced or ticketed. When it ends (or you click End now), an alert that is still live opens within a minute, so a problem the work didn't fix isn't lost. Alerts already open when maintenance starts stay open. Changing maintenance needs the permission to change RMM policies.
Tickets
A policy can name a connected PSA or RevoPSA under Open a ticket for each new alert in. Each new alert then becomes a ticket for the customer (for a connected PSA, the customer must be linked to a PSA company in Settings → Integrations). The alert links to its ticket. Muted alerts never open tickets.