Many companies say their systems are monitored. What they usually mean is that there is a dashboard — on a screen in the IT office, checked when someone remembers. That is watching. Monitoring is something else.
What has to be measured
Monitoring starts with the question: what would the business notice first? Usually not a CPU value, but a slow quotation, a failed import or an expired certificate. Those are the things to measure:
Each of these needs a threshold, and each threshold needs a decision: what happens when it is crossed?
An alert is only useful if someone can act on it
If the first indication of a fault is a sales person reporting it, the system is not monitored. But an alert that reaches someone who can only forward it is not much better. The person who receives the alert must have the access and the knowledge to fix the problem — at any hour.
That is also why we monitor our systems ourselves: the alerts go to the people who wrote the code. Why that matters is explained in Why In-House Hosting Is Like Building Your Own Aircraft.
The checks people forget
- Monitoring from outside, the way a customer reaches the system.
- Alerts when something did not happen — see The Silent Failure: When Automations Stop Without Telling Anyone.
- A test alert every month, to prove the chain still works.
- A clear escalation: who is called if the first person does not respond?
A dashboard tells you what happened. Monitoring tells the right person while it is happening.
Want monitoring that reaches people who can actually fix the problem? We build, run and monitor systems ourselves — and we know where automation pays off and where it becomes a risk.