"The server is down!" – and why that sentence would be avoidable
Sound familiar? Monday morning, you walk into the office and half the team is already standing in front of the IT cabinet. "The server is gone." What follows: frantic phone calls, stressed employees, the managing director asking every five minutes when it'll be back, and somewhere in the background a clock ticking, counting how much productivity is burning right now.
The frustrating part: the problem had announced itself. The hard drive had been 92% full for weeks. The backup logs had shown errors for three days. The CPU was constantly maxed out. All the signs were there – nobody was looking.
That's the difference between reactive and proactive IT – and exactly this principle drives us at Ovarna. Reactive IT is the fire brigade: wait until it burns, then extinguish. Proactive IT is fire prevention: install smoke detectors, check regularly and fix problems before they become fires.
What proactive monitoring actually does
At its core it's simple: software watches your IT systems around the clock and reports when something falls outside the norm. But as with most things, the devil is in the detail.
Good monitoring works in stages. Stage one is the availability check: is the device reachable? A simple ping, like knocking on the door. Stage two looks deeper: how is the device doing? CPU load, memory, disk capacity, network throughput. Stage three analyses logs – error messages, security events, warnings that applications spit out. And stage four, the supreme discipline, detects anomalies: deviations from normal behaviour that point to a problem that doesn't even exist yet.
For example: if your server normally runs at 30% CPU and suddenly sits constantly at 80%, that's not an outage yet. But it's a sign that something has changed. Maybe a process gone haywire. Maybe a cryptominer that an attacker smuggled in. Maybe just an application that needs more resources. In any case: something worth looking at before it turns into an outage.
The problem with too many alerts
This is where many make the decisive mistake. They set up monitoring, configure aggressive thresholds, and suddenly get 50 alerts a day. The IT manager becomes numb, starts ignoring alerts, and after three weeks the monitoring is turned down or switched off entirely. A classic case of "alert fatigue".
Good alerting is like a good employee: it reports the important things and handles the rest quietly. A tiered system helps. Informational messages are only shown in the dashboard – good for trends and reviews, but no notification. Warnings go out by email or chat – not urgent, but requiring action, for example when a disk drops below 15% free space. Critical alerts trigger SMS or phone calls – but only for real business impact, such as a production server being unreachable.
The key is the baseline: what is "normal" for your systems? If your server goes to 90% CPU every Friday afternoon because of the weekend backups, that's not worth an alert. If it suddenly hits 90% on a Tuesday at 2 p.m., it is.
Which solution suits you?
For SMEs there are essentially three paths.
Open-source tools such as Zabbix, Nagios or Prometheus with Grafana are powerful and free. The catch: you need someone to set them up, maintain them and understand them. The learning curve is steep and the operational effort is real. If you have an IT team that enjoys this kind of thing, it can be a good option.
Commercial SaaS solutions such as Datadog, New Relic or PRTG take operations off your hands. You pay per host or per sensor, but in return you get a ready-made system with updates and support. For Windows-heavy environments PRTG is particularly popular because setup is comparatively easy.
And then there's the third option, which is the most practical for most SMEs: managed monitoring as part of a managed services package. Someone else takes care not only of the software, but also of evaluating the alerts and responding to them. You don't have to worry about anything, but you get regular reports and the reassuring feeling that someone is watching.
What you should monitor – and what you can skip
Not everything needs to be monitored. Start with what's business-critical: your servers, the network infrastructure (switches, firewall, Wi-Fi), your business-critical applications and your backup system.
For servers the decisive metrics are: CPU load (warning above 80%, critical above 95%), RAM usage (warning above 85%), disk (warning below 20% free) and the status of the most important services. Plus an often forgotten but important check: certificate expiry. Nothing is more embarrassing than a website suddenly showing security warnings because someone forgot to renew the SSL certificate.
For the network: bandwidth utilisation, packet loss and latency. And one particularly useful feature: notification of new, unknown devices on the network. If a foreign device suddenly shows up, you want to know.
Security monitoring doesn't have to be an enterprise-scale SIEM. Start with the essentials: failed login attempts (many in a short time indicate a brute-force attack), logins at unusual times and administrative actions that don't fit the normal rhythm.
The first step is always the same
Whichever path you choose: start with an inventory. You can't monitor what you don't know. Which systems exist? Which are business-critical? What are the dependencies?
Then set up the basics: availability check for all critical systems, resource monitoring for the servers and sensible thresholds that fit your environment – not some best-practice table from the internet.
And then: keep at it. Adjust thresholds when the environment changes. Switch off alerts that were never relevant. Integrate new systems. Monitoring is not a one-off project but a living process.
The investment pays off. Fewer unplanned outages, shorter response times, better predictability and perhaps most importantly: calmer nights for everyone involved.
*How transparent is your IT? Let's take a look together in a free initial consultation. Book an appointment*
