Automation
Automation rules respond to events without human intervention. When an alert fires, an automation rule can run a script, reboot a device, or take other corrective action automatically.
Automation requires a paid plan.
Creating a rule
Go to Automation and click New rule.
Each rule has:
Trigger: what event starts the rule (currently: alert raised)
Match criteria: which alerts match (by severity, metric, or policy)
Actions: what to do when matched (run a script, reboot, log an event)
Cooldown: minimum time before the rule fires again for the same device
Example rules
| Rule | Trigger | Match | Action |
|---|---|---|---|
| Restart print spooler | Alert raised | Metric: service.spooler | Run script: restart-spooler.ps1 |
| Clear temp files on low disk | Alert raised | Metric: disk_percent, severity: warning | Run script: clear-temp.ps1 |
| Reboot on critical memory | Alert raised | Metric: memory_percent, severity: critical | Reboot with 5-minute delay |
Automation runs
The Automation page shows a log of every rule execution with:
Which rule fired
Which device triggered it
What action was taken
Whether it succeeded or failed
Timestamp
Filter by status (success, failed, skipped) or by trigger type.
Relationship with monitors
Component monitors can trigger alerts, which in turn trigger automation rules. This creates a self-healing chain: monitor detects a problem, alert fires, automation remediates, monitor confirms resolution.
Cooldown
Cooldown prevents automation rules from firing repeatedly for the same ongoing issue. If a disk space alert fires every 60 seconds, a 30-minute cooldown ensures the cleanup script only runs once per half hour.