Alert rules decide when a server's metrics are worth a notification. A rule names a metric, a threshold, how long the condition must last, and how serious it is.
Anatomy of a rule
CPU usage is above 90% for 5 minutes → Warning
- Metric: CPU usage, load average, memory, swap, disk, inode usage, network in, network out, zombie processes, failed SSH logins, sudo commands, disk errors, process crashes or out-of-memory kills. The "per report" metrics count what happened since the agent's previous report, set by Report every in the server's settings.
- Condition: above, at or above, below, or at or below a value.
- Duration: how long the condition must hold before alerting, from 0 (immediately) up to one day. Short spikes are ignored.
- Severity: Info, Warning or Critical. Critical alerts can open an incident automatically if your team turns that on.
- Applies to: all servers, every server with a tag (servers you tag later are included), or one server.
- Notify: pick which channels hear about this rule. Leave them all unticked to use every enabled channel.
When the condition clears, the alert resolves on its own and your channels get a recovery notice.
Recommended rules
The first time you open Rules, the Start with sensible defaults card offers these templates:
| Rule | Condition |
|---|---|
| High CPU | CPU above 90% for 5 minutes |
| High memory | Memory above 90% for 5 minutes |
| Disk filling up | Disk above 80% for 10 minutes |
| Disk almost full | Disk above 95%, critical, immediately |
| High load | Load above 8 for 10 minutes |
| Swapping heavily | Swap above 50% for 15 minutes |
| Running out of inodes | Inodes above 90% for 10 minutes, critical |
| Process killed for memory | Any out-of-memory kill, critical, immediately |
| SSH login attack | More than 20 failed SSH logins per report for 5 minutes |
| Zombie processes piling up | Zombie processes above 20 for 15 minutes |
The four marked Recommended are ticked for you. Pick the ones you want and choose Add selected. They apply to all servers and notify all channels. Use the pencil (Customize) to adjust one first. Templates you haven't added yet stay available under Quick add.
Built-in alerts
Some alerts don't need a rule. You always get them:
- Server offline when the agent stops reporting.
- Service down and Container problem for the services you watch and your Docker containers.
- Disk filling up from the disk forecast.
- New open port, Firewall turned off, User account change, System error and Database or web server problem from the agent. See Services and containers.
- Monitor down, SSL certificate and domain expiring from uptime monitors.
- Heartbeat missed and heartbeat failed from heartbeats.
Acknowledging and resolving
- Acknowledge an alert to tell your team you're on it. It stops any escalation. Every alert notification has an acknowledge link (a button in Slack and Telegram). It works for 3 days without signing in: open it and press I'm on it — acknowledge.
- Resolve an alert yourself when you know it's fixed. Rule alerts also resolve automatically once the metric recovers. Resolving by hand doesn't send a recovery notice, and if the problem is still there, a new alert opens.
AI help
When AI features are on, each alert has an Explain with AI button. It describes what happened, the likely causes and what to check first, and you can Regenerate it later. To do that, Alertly.Net sends the alert, the server's name, operating system and recent metrics, and any failing services to the AI provider. Alert notifications also include a one-line Likely cause.
Owners and admins can turn this off under AI features in the team settings. Nothing from the team is sent to the AI provider then.
Noisy rules
Rules that fired at least 10 times in the last 7 days are marked Noisy, and rules whose alerts keep recovering within 5 minutes are marked Flapping. With AI features on, Tune with AI suggests better thresholds or durations. It doesn't change anything for you.
Tips
- Use a duration of at least a few minutes for CPU and load. Brief spikes are normal.
- Make Disk almost full critical and immediate. Running out of disk breaks databases.
- A server-specific rule adds to team-wide rules; it doesn't replace them. For machines that are always busy, tag them (for example
busy) and aim strict rules at your other tags instead of all servers.