CPU and load average
A high CPU usage alert helps identify sustained pressure rather than a brief burst of work. Compare CPU use with queued work through CPU and load monitoring.
Server Alerts You Can Act On
CloudStats watches your Linux servers and sends server alerts when a problem lasts long enough to need attention, not when a graph jumps for a second. Send the message to a channel your team already uses, with a clear severity and a recovery message when the condition clears.
Alert rules that ignore the noise
Useful server monitoring alerts start with a condition that lasts, a severity and a destination.
Thresholds with a duration
Use CPU above 90% for 5 minutes, or free disk space below 10% for 10 minutes. The threshold describes the problem; the duration stops a short spike from becoming an interruption. Choose a duration that separates normal workload changes from something worth investigating.
Warning and critical levels
One rule can have two thresholds. For disk space, warn below 10% free and mark below 5% as critical, with a 10-minute duration. The warning gives someone time to investigate; the critical level makes a more urgent condition clear.
Recovery notifications
Send a message when the condition clears. Recovery notifications let responders see that the problem has ended without repeatedly opening a chart or checking the server by hand. Keep the recovery alongside the original notification so the team can follow the incident.
Escalation and maintenance windows
Use alert escalation to notify another channel or person when a critical condition stays open. During planned work, mute notifications with a maintenance window so an expected restart does not interrupt the team. Review the affected rules before beginning the work.
What you can alert on
Memory
Watch memory pressure so a busy workload does not quietly become an unresponsive server. Put the condition in context with memory monitoring.
Disk space and I/O
A low disk space alert gives you time to investigate growth before a filesystem fills. Check I/O pressure separately to distinguish capacity problems from slow storage.
Network
Watch network activity for sustained changes that need investigation. Compare the condition with the workload before choosing a threshold that would interrupt someone.
Server down / not reporting
A reporting gap may mean the host is unreachable or its agent has stopped sending data. Use server uptime monitoring to make that condition actionable.
Ping and port checks
Detect a failed reachability check or a port that no longer accepts a connection. Use ping and port checks to describe the specific failure you need to investigate.
Website down
A failed HTTP check can identify an unavailable website even when the underlying server still reports. Connect the rule to website availability checks.
Cron job missed or failed
A scheduled task can fail without making the server itself unavailable. Use cron job monitoring to distinguish a missed run from a reported failure.
SSL certificate expiring
Act when a certificate is close to expiry instead of waiting for visitors to encounter it. Follow up through SSL certificate expiry monitoring.
Notification channels
Rules can route to different channels: warnings to Slack, for example, and critical conditions to Telegram and email. Available channels depend on your plan.
Send notifications to an inbox watched by the people responsible for the server. Keep ownership clear when choosing the recipient.
Slack
Post Slack alerts to a channel your team already follows. Use a destination where someone can take responsibility for the condition.
Telegram
Send Telegram alerts to a chat or group. Choose the conversation used by the people responding to critical problems.
Webhook
Deliver webhook alerts as a JSON payload to your own HTTPS endpoint or on-call tool. Connect the message to your existing response workflow.
Fewer, better alerts
Alert fatigue starts when a notification rarely needs a response. People learn to ignore the channel, and a real failure becomes harder to notice. Useful server alerting gives each message a reason to interrupt someone.
Set a duration that allows normal bursts to pass. Separate a warning worth investigating from a critical condition that needs attention now. Keep recovery messages in the same workflow so resolved problems do not look open.
Review monitoring alerts after an incident: was the threshold useful, did the right person receive it, and was recovery clear? Better server alerts come from those decisions, not from adding more notifications.
Example rules
| Condition | Level | Channel |
|---|---|---|
| CPU above 90% for 5 min | Warning | Slack |
| Free disk space below 5% for 10 min | Critical | Telegram + email |
| Server not reporting for 3 min | Critical | Telegram + email |
| Disk usage above 90% for 10 min | Critical | Slack + webhook |
| Cron job missed | Warning |
FAQ
FAQ
How do I get alerted when my server goes down?
To alert when a server goes down, create a rule for the server not reporting and choose how long the condition must last. Select the notification channels your responders use. A server down notification tells you to investigate; check connectivity and the reporting agent before deciding the host itself has failed.
Can I send server alerts to Slack or Telegram?
Yes. Route messages to a Slack channel or a Telegram chat or group, and choose the destination for each rule. You can send warnings to Slack and critical conditions to Telegram and email. Keep the destinations aligned with who is responsible for responding to that server.
How do I avoid getting too many alerts?
Start with a duration that excludes normal short spikes, then separate warning conditions from critical ones. Adjust thresholds to the workload instead of treating every busy period as a fault. Use maintenance windows for planned work, and keep recovery messages enabled so people know when an incident no longer needs attention.
Will I be notified when the problem is fixed?
Yes. A recovery notification is sent when the condition clears. It closes the loop in the same workflow as the original problem, rather than leaving someone to check the chart repeatedly. Responders can then distinguish an active issue from a message about a condition that has already ended.
Can I pause alerts during maintenance?
Yes. Mute notifications during planned maintenance so an expected restart or service stop does not interrupt the team. Choose the maintenance window around the work you are doing, and check the affected rules before starting. After the window, review the current condition rather than assuming the work removed every problem.