How does your company find out something is broken today? For most SMEs the honest answer is: through a human. An employee who can’t log in, a customer calling because the webshop won’t load, an accountant whose report won’t run. The system may have failed at 02:14. You hear about it at 09:30. Those seven hours are the most expensive part of the whole incident.
Incident detection is about closing exactly that gap. Not preventing things from ever breaking, because nobody manages that, but bringing the moment of knowing as close as possible to the moment of happening.
How detection works, without the jargon
A monitoring platform continuously measures a long list of signals: is this service still responding, how full is that disk, how long does that web page take to answer, when does that certificate expire. Every signal gets compared against what’s normal. When it deviates, an alert follows.
It sounds simple, and the basics genuinely are. A service that stops responding is known within a minute. A disk filling up announces itself days in advance. A certificate expiring in two weeks never needs to be a surprise. A good share of “sudden” incidents are in reality a slow train that was visibly approaching for weeks. Nobody was watching the track.
The trap: noise
There is one reliable way to ruin monitoring, and that’s poor tuning. A platform sending a hundred alerts a day gets ignored within a week, including the hundred-and-first alert that turns out to be the real one. I’ve watched teams in enterprise environments grow collectively alarm-fatigued, and that pattern is even more dangerous at an SME, where no control room exists to look at the alerts regardless.
Good tuning means making choices. What is critical enough to wake someone at night? What can wait until morning? What is normal for your environment specifically? A backup server that spikes network traffic every night is not an incident. That same spike at three in the afternoon might be. That context doesn’t get built in an afternoon, and it’s the difference between a watchdog and a dog that just barks.
What detection is worth on paper
Beyond the operational win there’s a second return: evidence. Every detection and every follow-up is recorded with a timestamp. Anyone who has ever filled in a supplier questionnaire from a NIS2 client will recognise the question immediately: “do you detect incidents, and how quickly?” With an alert history the answer isn’t a promise. It’s a report you can attach.
Where to start
Don’t start by trying to monitor everything. Start with the question: which three systems hurt the most when they go down? For most SMEs that’s the mail environment, the accounting or ERP application, and the website or webshop. Put detection on those, tune it properly, and expand once that runs.
Through Althona I set up exactly that kind of environment with CheckMK, tuned to what’s normal for your business, with alerts that only fire when they should. Want to know how quickly you’d notice an outage today? Book a no-obligation call. The honest answer to that question is often half the business case by itself.