MENU

A server can look perfectly healthy right up until the moment staff cannot open files, customers cannot place orders, or a backup fails when it is needed most. A good guide to server monitoring is not about watching graphs all day. It is about finding problems early, knowing which warnings need action, and keeping essential business systems available.

For a small business, a server may run shared files, email, accounting software, a website, a database, remote access or a private cloud. When one of these services stops, the cost is usually measured in lost working time, frustrated customers and rushed repair work. Monitoring gives you warning before a minor fault becomes an outage.

What server monitoring should tell you

Server monitoring collects information about the condition and performance of a server and the services it provides. The aim is simple: confirm that the hardware, operating system, network and applications are working as expected.

That sounds broad because it is. A server can be switched on and reachable while the service people actually need has failed. For example, a file server may respond to a network check but have no free disk space left. A mail server may be running but unable to send messages because its storage is full or its certificate has expired.

Useful monitoring therefore answers practical questions. Is the server online? Is it under unusual load? Is there enough storage for normal work and backups? Are critical applications responding? Has a backup completed successfully? Can users reach the service from where they normally work?

The right level of detail depends on the system. A simple office file server needs a different setup from a database server handling customer data or an on-site virtualisation host running several business-critical machines.

Start with the services, not the software

Before choosing a monitoring platform, list what would stop the business from operating if it failed. This is more useful than starting with a long list of technical metrics.

For many small organisations, priorities include shared folders, cloud file sync, email, internet connectivity, VPN access, line-of-business applications, databases and backups. Add the hardware that supports them, including firewalls, switches, network storage and uninterruptible power supplies where relevant.

Then decide how quickly each issue must be noticed. A failed backup may not need an out-of-hours phone call, but it should be checked promptly the next working day. A server that is offline, a failed RAID drive or a VPN outage affecting remote staff may need immediate action.

This process avoids a common mistake: setting alerts for every possible event. If every minor warning produces a notification, real faults get buried. People begin ignoring alerts, and the system becomes noise rather than protection.

The core checks to monitor

Availability and network reachability

The basic check is whether the server can be reached over the network. This quickly highlights power, connectivity and operating-system failures. It is useful, but it is only the first layer.

Monitor the network path as well. If a server is working but the firewall, switch or internet connection has failed, staff may still be unable to use it. Remote services such as VPN, hosted applications and email need checks from outside the local network too.

For sites with a single broadband connection, monitoring the connection can also reveal recurring dropouts or poor stability. That gives you evidence when speaking to the provider rather than relying on occasional complaints from staff.

CPU, memory and system load

High CPU use is not always a fault. A scheduled report, overnight backup or antivirus scan can legitimately create a short spike. Persistent high use, however, can make applications slow or unresponsive.

Memory usage needs the same judgement. Modern operating systems often use available memory for caching, so a high percentage is not automatically bad. Look for sustained pressure, swapping to disk, repeated application crashes or a trend that gets worse over days. Those signs can point to an undersized server, a misbehaving application or a memory leak.

Set alerts around duration rather than one brief peak. A warning after sustained high load is generally more useful than an alert every time normal work causes a short increase.

Storage capacity and disk health

Low free space is one of the most preventable causes of server trouble. Databases, log files, email stores and backups can grow quietly until the server has no room left to work properly.

Monitor free space on every important volume, including backup destinations. Use two thresholds: an early warning that gives time to investigate, followed by a critical alert that needs action. The percentage should reflect disk size. Ten per cent free on a 100 GB system disk is very different from ten per cent free on a 20 TB storage array.

Capacity alone is not enough. Watch disk health, RAID status and failed or degraded drives. A RAID array can keep working after one drive fails, but it is then operating with less protection. Replacing the failed drive quickly is far safer than discovering a second failure during a rebuild.

Services and applications

This is where server monitoring becomes genuinely useful to staff. Check the service people depend on, not just the server underneath it.

A file server check might confirm that a shared folder can be opened and written to. A database check might confirm that the service is accepting connections. A web application check should test that it returns the expected page or response, not merely that port 443 is open. Mail monitoring can verify that messages are being processed and queues are not building up.

Application-level checks take more initial setup, but they catch the failures that basic ping checks miss. They also make it easier to identify whether the problem is with the server, the network or the application itself.

Backups and recovery jobs

A backup job marked as successful is useful evidence, not a recovery plan. Monitor whether jobs run on schedule, how long they take, whether warnings are increasing and whether the backup storage is healthy.

Most importantly, test restores. A backup may complete without errors while still being incomplete, encrypted by malware or unusable in practice. Test a small file restore regularly and plan periodic recovery tests for critical systems. Record how long recovery takes, because recovery time matters as much as whether it is technically possible.

Alerting that people will act on

Alerts should be routed to someone with the authority and knowledge to respond. For a small business, that might be an outsourced IT provider, an internal manager or both. It should never rely on one person who is on holiday or unavailable.

Use clear severity levels. Critical alerts need an immediate response because a service is down, data protection is reduced or there is a security concern. Warnings should prompt investigation before users are affected. Informational messages can be retained in reports without sending a notification every time.

Every alert should say what has happened, which system is affected and what to check first. “Disk space low on FILESERVER01, volume D: at 92% used” is actionable. “Warning event detected” is not.

Escalation matters too. If an alert is not acknowledged, it should be sent to another contact after an agreed time. This is particularly valuable for failed backups, hardware alerts and systems supporting remote workers.

Monitoring supports security, but does not replace it

Monitoring can highlight unexpected restarts, failed login attempts, sudden storage growth, unusual network traffic and disabled backup jobs. These can all indicate a security issue. It also provides a timeline that helps investigate what happened after an incident.

However, monitoring is not a substitute for patching, multi-factor authentication, access control, endpoint protection and tested backups. A monitoring platform can tell you that a server is working normally while an attacker has access to data through a compromised account.

Keep monitoring accounts separate, use strong authentication and restrict who can change alert settings. An attacker who can disable alerts has more time to cause damage unnoticed.

Build a monitoring routine that stays useful

Installing a dashboard is only the start. Review it regularly. Check capacity trends monthly, particularly storage growth, backup duration and recurring performance issues. A server that has gradually become slow over six months is easier and cheaper to deal with before it reaches its limit.

Review alerts after every incident. If a notification was ignored because it was unclear or unnecessary, adjust it. If an outage occurred without an alert, add the missing check. Monitoring should improve as your systems and working patterns change.

Document the basics: server names, purpose, key services, owners, backup locations and response steps. This makes support faster when the usual contact is unavailable. For Dundee businesses without an internal IT team, DCC Workshop can also help put sensible monitoring around existing servers without turning a straightforward setup into an overcomplicated project.

The best monitoring setup is one that gives you enough warning to fix a problem during normal working hours. Start with the systems your team would miss first, test the alerts, and keep refining them until every notification earns attention.