Monitoring is often just a word in the contract
A sentence about monitoring appears in almost every IT support proposal. On its own it means nothing. You can have a tool that checks every minute whether the servers answer a ping and call that monitoring. You can have charts nobody looks at. You can have alerts landing in a mailbox that already holds a thousand of them.
The difference between having monitoring and knowing what is going on comes down to three things. Whether the things that actually break are being watched. Whether a deviation from normal reaches a named person. Whether somebody sits down once a month and says what it all means.
There is a simple test. Ask your provider how many times in the last quarter monitoring caught a problem before any member of staff reported it. A specific answer means the tool is working. A vague answer usually means monitoring is there to confirm failures rather than to get ahead of them.
This is not an accusation aimed at providers. Monitoring is the part of a contract that most easily stays at the level of a declaration, because nobody checks it while everything works. It is worth checking earlier.
What actually needs to be watched
The list is not long and it is no secret. It is worth keeping at hand, because it shows very quickly what a given contract is missing:
- availability, meaning whether the service responds. Not just whether the server answers a ping, but whether the things people use are working: the website, the database, email, the file share, the sales system
- link saturation. A link that runs at the edge of its capacity during working hours is formally up, but everything on it slows down and nobody can say why
- response times of network nodes. Rising latency and dropped packets usually show up long before the failure somebody finally gets stuck on
- disk space. A full disk stops a database, a mail queue or a backup job, and it is the single most predictable failure in all of IT
- processor and memory load, watched as a trend rather than as one reading. A server that has been creeping upwards for three months will eventually hit the ceiling
- backup status. Not merely a confirmation that the job ran, but whether it covered what it was meant to cover, how long it took and whether it fitted into the window
- errors in system and device logs. Not all of them, only selected patterns, because otherwise nobody will read them even once
- expiring certificates. This is a failure with a date set in advance, so there is no reason at all for it to surprise anybody
On top of that come items specific to a particular company. The state of the uninterruptible power supplies, the temperature in the rack, queues in the warehouse system, the response time of the one application the whole department depends on. A provider who knows your environment will ask about these unprompted. If nobody asked, the monitoring was most likely set up from a template.
Certificates now expire more often
An expiring certificate is the most predictable failure in company IT and at the same time one of the most common. The effect is immediate and visible to customers: a browser warning, a broken integration between systems, a phone application that stops connecting to the server.
This subject has just become harder. In April 2025 the CA/Browser Forum adopted a schedule for shortening the maximum validity period of public TLS certificates. Until 14 March 2026 it was 398 days. From 15 March 2026 the limit is 200 days, from 15 March 2027 it becomes 100 days, and from 15 March 2029 it will be 47 days. The period during which an earlier domain validation can be reused is shrinking as well, eventually down to 10 days.
In practice this means one thing. A certificate that used to be replaced once a year alongside other work will have to be replaced several times a year, and within a few years almost monthly. A list in a spreadsheet and a calendar reminder stop being enough, because the mistake will happen at one of those repeated deadlines.
So the question for a provider is very specific. How do you know when each of our certificates expires, how many days in advance do we hear about it, and is the renewal automated. If the answer is that somebody remembers, that is not an answer.
An alert and a report are two different things
An alert is about right now. Its job is to tell one person that something is happening, and to do it early enough that there is still time to act before the consequence. An alert with no recipient is not an alert, it is an entry in a history log.
A report is about the trend. Its job is to show what happened over a month, what is getting worse and what is worth doing before it turns into a failure. A report is not there to prove that everything was fine. It is there to support decisions about money: whether to add disks, whether to increase link capacity, whether to replace a switch that drops packets.
Mixing the two is a common mistake. A list of every alert from the past month is not a report, it is a printout. On the other hand, a report where every indicator is green while users spent three weeks complaining about slow work does not describe that company, only a selection of charts.
Without a threshold and a recipient an alert is just a chart
Monitoring starts working the moment somebody sets thresholds. Not the general notion that a disk is filling up, but specifics: at which value a warning appears, at which value an alarm does, and how long the condition has to persist before a notification goes out. Without that last condition one brief spike will wake somebody up at night for no reason.
The second thing is the recipient. An alert should have one person or one duty rota on the other side, a channel matched to how serious the matter is, and an agreed path for when nobody responds. Notifications can go by email, by text message or to a team chat, depending on how urgent the case is and what time of day it happens. The point is that this split is agreed in advance rather than picked during an outage.
The third thing is hygiene. An alert that fires every day and means nothing stops being read after two weeks, and every other alert stops being read along with it. That is why thresholds have to be corrected and notifications that lead to no action simply removed. This is a normal part of maintenance, not proof that the monitoring was built badly.
If the contract holds neither thresholds nor a recipient, monitoring is a chart. A pretty one, but it will not wake anybody up.
What an honest monthly report looks like
An honest report can be read in a few minutes and it tells you what to do. It does not have to be long. It has to contain the things that are not visible from day to day correspondence:
- what happened: tickets and failures, when they arrived, when somebody picked them up, when they were closed
- how many problems monitoring caught before a user reported them, because that is the only measure that shows whether monitoring is really working
- capacity trends: disks, links, memory, with a plain conclusion about when the headroom runs out
- backup status, together with whether a test restore was performed in that period and how it ended
- what changed in the infrastructure, who asked for it and when
- open risks and recommendations with reasoning behind them, not just a shopping list
A report that contains not a single thing that went wrong deserves particularly careful reading. No infrastructure has a month without a stumble. A provider who describes those stumbles unprompted is easier to work with than one where everything only comes out during a major failure.
It is also worth agreeing whether the report is generated automatically or whether somebody reads it before it is sent. An automated tool sends the same thing every month. A person adds one sentence about what worried them, and that sentence usually costs less than the failure it warns about.
Questions worth asking your provider
This is the shortest route to finding out how things stand at your end. None of these questions is hostile and every one of them can be answered in a few sentences:
- what exactly is monitored. Ask for a list of devices and services, not for reassurance
- what the warning and alarm thresholds are for disks, links, processor and memory
- who receives an alert in the middle of the night and at the weekend, and what happens if that person does not respond
- whether out of hours duty is written into the contract or is a matter of goodwill
- where the monitoring physically runs and who owns the collected data
- what stays with us if we change providers: configuration, history, access to the data
- how long metrics and logs are retained, because without history there is no trend at all
- whether we can have read only access to a dashboard with the current state
- whether backups are verified with a test restore and how often
- whether we can see a sample monthly report, even with another client data redacted
That last question is usually the most telling. A provider who reports regularly has such a document at hand and will show it without preparation. If the sample report has to be produced first, it means none existed until now.
How we approach this ourselves
We run monitoring in Elastic Stack, on the infrastructure of the client. Data from network devices is collected by Logstash over SNMP and syslog, while servers and systems send theirs through Filebeat, Winlogbeat and Metricbeat. Alerts go by email, by text message or to a chat, depending on how serious the matter is. In this model we look after several thousand devices.
Keeping the solution on the client side was a deliberate choice. The data stays inside the company, thresholds are set for that specific environment, and the operational view is built so that it answers the question of what is wrong right now within tens of seconds. The scope of support, including round the clock duty, is agreed in the contract, because that is a condition which should be written down rather than assumed. Tickets are ordered by what blocks work the most.
If you simply want to check what is watched at your site today and what is not, walk through the list of questions from this article with your current provider. The answers usually paint a very clear picture. If that picture shows more gaps than calm, we are happy to sit down and work through it with you.