Monitoring lets you spot problems with critical areas such as disks, backups, certificates and UPS units before users notice. The right thresholds and notification channels keep alerts from turning into noise.
In many businesses, a server disk filling up, backups silently failing for days or a website certificate expiring only comes to light when an employee complains or a customer calls. Monitoring is the routine of checking your systems regularly and alerting you when something starts to go wrong. The aim is not to measure everything, but to spot the problems that could stop your business before your users do.
What does monitoring change?
Without monitoring, IT problems are usually dealt with once they "blow up": the file server can't be reached, email isn't going out, the accounting software won't open. With monitoring, many of the same problems become visible at an earlier stage. You see disk usage climbing before the disk is full, get an alert the morning after a backup fails, and receive a reminder weeks before a certificate expires. That lets you respond during working hours, in a planned and calm way.
Monitoring tools usually collect information in one of two ways: through a small piece of software (an agent) installed on the device, or by querying the standard interfaces the device offers. For network equipment, printers and UPS units, the common method is SNMP, a long-established network management protocol used to read device status. Which method is used depends on the device and the tool you choose; what matters is that you decide first what should be monitored.
What should be monitored?
Availability
The most basic question is whether the device and the service are up. A server answering on the network does not mean the service running on it is working. So rather than just asking the device "are you there?", check the services that matter to the business separately: is the file share responding, is the database accepting connections, is the website returning the right page? For the website and other internet-facing services, it also matters that some checks run from outside the office; if the office internet line goes down, a monitoring system inside may not be able to report it on its own.
Disk usage and disk health
A full disk can stop databases, prevent email from being received and leave backups half-finished. Look not only at current usage but also at the rate of growth: for a disk that grows by a certain amount every week, the answer to "at this rate, when will it be full?" lets you make the purchasing decision in time. Alongside usage, monitor disk health too. Disks can signal some failures in advance through self-monitoring data known as SMART. If you use RAID (a setup where several disks work together so that one can fail without data loss), a failed disk can go unnoticed precisely because the system keeps running; make sure this condition always triggers an alert.
CPU and memory
Short spikes in CPU and memory use are normal; values may look high for a while when a report is being generated or an update is installing. What really matters is usage that stays high for a long time and a trend that creeps up over weeks. This information helps you understand whether a "the server is slow" complaint really comes from the hardware, and base replacement decisions on data.
Backup jobs
Most backup software can send a notification when a job fails. A more insidious situation, however, is a job that never runs at all: the scheduled task may have been deleted, the service may have stopped or the notification settings may be broken. So as well as "failed" notifications, turn "no success report within the expected time" into an alert too. A sudden drop or jump in backup size is also worth investigating. Whether a backup that looks successful can actually be restored can only be confirmed through regular restore tests.
Certificate and domain expiry dates
The SSL/TLS certificates (digital documents that encrypt the connection between the browser and the server) used by your website and email service have a validity period. An expired certificate causes security warnings in visitors' browsers and can stop some applications from connecting. As the validity periods of publicly trusted certificates keep getting shorter, automating renewal and tracking expiry dates separately is becoming more important. Don't forget domain renewal either: when a domain expires, the website and email can stop together. Getting an alert a few weeks before the expiry date leaves time to deal with setbacks such as a changed payment card or the responsible person having left.
UPS and power
An uninterruptible power supply (UPS) keeps servers running for a short time when the power goes out. The conditions to monitor are: the UPS switching to battery, remaining runtime getting low, a failed battery test and the UPS losing its connection. Also check that servers are configured to shut down cleanly during a long outage. Batteries wear out over time; a UPS whose battery is due for replacement may last much less than expected when an outage happens.
| Monitored area | Early warning sign | Possible impact |
|---|---|---|
| Service availability | The service has not responded for a set period | Staff or customers cannot reach the service |
| Disk | Usage growing fast, SMART or RAID warning | Applications stop, risk of data loss |
| Backup | Job failed or no result within the expected time | No recent copy to fall back on after a failure |
| Certificate / domain | Expiry date approaching | Site shows a security warning, email may be affected |
| UPS | Switched to battery, battery test failed | Servers may stop without shutting down cleanly |
Thresholds and alert fatigue
The most common reason monitoring fails is human rather than technical: too many alerts arrive, most turn out to be unimportant, and after a while nobody looks at them. This is called alert fatigue. The alert that really matters gets lost among hundreds of unnecessary emails.
There are a few practical ways to prevent this. Define alerts on at least two levels: "warning" for situations that should be looked at on the next working day, and "critical" for situations that need immediate action. For example, you can set a warning threshold and a higher critical threshold for disk usage; the right values depend on the size of the disk and how fast it grows, so adjust your starting values after observing them for a few weeks. Add a duration condition to filter out short fluctuations: an alert should be raised not when the CPU spikes for a moment, but when it stays high for a set period.
Defining dependencies also reduces noise. When the core switch or the internet line goes down, getting one meaningful alert instead of a separate alert for every device behind it points straight to the source of the problem. During planned maintenance, temporarily silence alerts for the affected devices and make sure they are switched back on when the work is finished.
For every alert, ask "What will we do when this alert arrives?" An alert with no answer, or one that is always ignored, should either be removed or have its threshold changed. Conversely, if a problem was not spotted before users noticed it despite monitoring, add the check that was missing.
Who should receive alerts, and how?
The notification channel should match the importance of the alert. For low-priority alerts, a daily or weekly summary email may be enough. Critical alerts should go to a channel that is hard to miss, such as an instant phone notification, SMS or a business messaging app. If you rely on email alone, remember that when the email server itself goes down, the alert will not arrive either.
Sending alerts to a role-based address or group rather than one person's own mailbox avoids gaps when that person is on leave or leaves the company. Decide from the outset who looks at alerts outside working hours, and who the alert is passed on to if there is no response after a set time (escalation). If you use external support, be clear about which alerts go straight to the support team and which ones you will be informed about.
Finally, monitor the monitoring system itself. If the monitoring server shuts down or can no longer send notifications, the absence of alerts gives the impression that all is well. Expecting a regular "still running" signal from outside and getting an alert when that signal stops closes this gap. Once a month, deliberately triggering an alert and checking that the notification reaches the right people is also a good habit.
Checklist
- Are business-critical services monitored at the service level as well as the device level?
- Are the website and internet-facing services also checked from outside the office?
- Are there alerts for disk usage, growth rate, disk health and RAID status?
- Do backup checks catch both failed jobs and jobs that never ran?
- Do certificate and domain expiry alerts arrive weeks in advance?
- Are the UPS switching to battery and battery condition monitored, and are servers set to shut down cleanly?
- Are alerts split by severity, with short fluctuations filtered out by a duration condition?
- Do critical alerts go to a role-based channel, and is the monitoring system itself being checked?