Monitoring has two jobs: telling you when something needs attention now, and giving you the data to understand problems and plan ahead. Mixing those jobs up is why many teams drown in alerts.
Alert on symptoms
Page someone when users are affected or about to be:
- The service is down or failing health checks, checked from outside your network.
- Error rates are high.
- Response times are well above normal.
- A certificate expires within days.
- Disk space will run out within hours at the current rate.
- Backups have failed or not run.
- A security event needs action, such as repeated admin login failures.
Record causes
Collect, graph and keep the underlying metrics, but do not wake anyone for them on their own:
- CPU, memory, disk and network utilisation.
- Database connections, query times, replication lag.
- Queue lengths, cache hit rates.
- Hardware health: drive warnings, memory errors, temperatures.
These explain why a symptom happened and show trends for capacity planning.
Make every alert actionable
For each alert, someone should know what it means and what to do. If an alert fires often and nobody acts, fix the cause, change the threshold, or turn it into a report instead. Write a short runbook entry for each important alert.
Check from the outside
Internal metrics can look healthy while customers cannot connect because of DNS, a certificate or a network problem. External checks of your website, API and mail, from more than one location, catch what the server cannot see.
Watch the watcher
Monitor the monitoring system itself, and make sure alerts reach people through more than one channel.
How IDX helps
IDX NOC services provide monitoring and incident response for the infrastructure we host for you, with alerts and thresholds agreed with your team. Our managed servers service includes monitoring as standard.
IDX on digital infrastructure
Back to blog →