Insights — Operations
Failures do not arrive by surprise: they warn you for weeks.
A disk filling up, latency creeping 10 % a month, a backup failing silently for six days: serious incidents are almost always announced. Here are the seven signals we watch first, and the threshold at which we intervene.
01 — The problem
Classic monitoring tells you when it is already too late.
Most tools only report whether a service responds. That is necessary, but it prevents nothing: the moment a service stops responding, the incident has already happened and users have already noticed.
Preventive maintenance changes the question: not “is it down?”, but “what is filling up, slowing down or ageing faster than expected?”. Those are trend measurements, not state measurements.
01The seven signals, and why those
We settled on seven indicators because they announce most of the incidents we encounter, and because they can be measured on any kind of estate, from a physical server to a serverless function.
- Disk usage as a trend, not an absolute value: the slope is what announces saturation
- Response latency of critical services, compared with their own thirty-day average
- Backup failure rate, and the age of the last tested restore
- Certificate and domain expiry, with thirty days of warning
- Hardware wear: reallocated sectors, temperature, power-on hours
- Queues and late scheduled jobs, the first sign of saturation
- Silent application errors: swallowed exceptions, abandoned requests
02An alert without a procedure is noise
A useful alert contains three things: what is happening, what to do, and who acts. Without a written procedure, the alert is forwarded to whoever is available — and if they are on leave, the incident waits.
Every alert in our setup references a runbook: the commands to run, the decision to take, the possible rollback. A runbook must be re-read and rehearsed, otherwise it becomes obsolete without anyone noticing.
03Thresholds, not symptoms
We set thresholds per asset and per usage, never universal ones. A disk at 85 % on an archive server has nothing in common with a disk at 85 % on an active database: the question is the time remaining before saturation, given the observed slope.
That trend-based reasoning removes most false alerts, and it is what allows teams to trust monitoring: when an alert fires, it must mean something.
04The monthly report that changes decisions
Measurements are useless if they stay in a dashboard nobody opens. We produce a short monthly report: what drifted, what was fixed, what still needs a decision, and the replacement budget to plan.
That document is what allows a board to decide on renewing an estate before the failure, instead of enduring it at the worst possible moment, in a hurry, with no price comparison.
From measurement to decision: collect, correlate, alert, and know what to do before the user notices anything.
02 — Common questions
What technical teams ask us
Do we need an agent on every machine?
It depends on the estate. For servers and workstations you control, a lightweight agent gives the finest measurement. For everything else we query existing interfaces — hypervisor, network equipment, storage array — without installing anything on user workstations.
How long does it take to set up useful monitoring?
The foundation takes one to two weeks: collection, dashboard, trend thresholds and the first alerts with procedures. Then the setup is refined: we remove useless alerts and add the indicators that real usage has made relevant.
What happens outside business hours?
On-call is part of the setup, with a contractual response commitment. Critical alerts trigger a call, not an email nobody will read on Monday morning; comfort alerts wait for the next working day.
Would you like to stop discovering failures in the morning?
Survey of your estate, selection of useful signals, deployment of monitoring and procedures, then a monthly drift report.