IT monitoring that works – what should you measure and when should someone act?

IT monitoring that works – what should you measure and when should someone act?

More metrics do not give better control. How to build monitoring with the right metrics, calibrated thresholds, alerts that have a recipient and a clear escalation model.

Published

Summary: IT monitoring creates no value simply by collecting more metrics. What matters is detecting the things that actually affect the business and making sure the right person acts at the right time. A working monitoring model therefore needs to connect technology, thresholds, alerts, incident management and the availability requirements of the business.

It is relatively easy to monitor a lot: CPU, memory, disk, ping, network traffic, response time, logs, services, certificates and backup jobs.

The problem is that more data does not automatically give better control. A monitoring platform that sends 500 alerts a week can in practice give a worse overview than an environment that sends ten relevant ones. Because when everything is important, in the end nothing is.

Monitoring should answer a business question

The technical metric is rarely the goal. CPU at 95 per cent is not automatically a problem. It may be completely normal for that system. CPU at 70 per cent, on the other hand, may be critical if it normally sits at 10 per cent and response times have suddenly tripled.

The organisation therefore needs to understand what a technical metric means for the service the business uses. Only then does monitoring become useful.

Three perspectives on monitoring

We find it practical to separate at least three levels.

Infrastructure

Are the technical components working? This covers CPU, memory, disk, network ports, switches, firewalls, virtual machines and databases.

Service and user experience

Does the thing the user actually needs work? Does the website open? Does the API respond? Does sign-in work? Can the database complete a transaction? Does a critical integration work?

A server can technically be up. But the service can still be unusable.

Security

Are there events that need to be analysed from a security perspective? The Swedish National Cyber Security Centre (NCSC) makes “ensure the ability to detect security events” measure 1 of its ten recommended security measures, with logging and monitoring as central parts. Security logs also need to be protected against unauthorised access and modification, since otherwise they can be tampered with by whoever caused the event.

The same technical environment may therefore need monitoring from several perspectives.

Start with the critical services

It is tempting to start with the technology. We have 30 servers, let us add all 30 to monitoring. That is not wrong. But a better question first is: which services does the business depend on most? And then: which components does that service rest on?

A critical service may require:

  • internet connectivity
  • firewall
  • DNS
  • identity service
  • application server
  • database
  • storage
  • external API provider

If only the application server is monitored, a large part of the picture is missing.

An alert must have a recipient

A common problem in monitoring solutions is that the system reports something is wrong, but nobody really knows who should act, when or how.

A working model therefore needs to define:

  • What should raise an alert?
  • What severity does the event have?
  • Who receives the alert?
  • When is someone expected to react?
  • What happens if that person does not react?

A monitoring tool normally separates data collection, conditions that fire on problem states and actions that govern what should happen, including notifications. Notifications can be sent through several channels, for example email, scripts or webhooks.

The technology can send the alert. But the organisation still has to decide what the alert should lead to.

Round-the-clock monitoring is not the same as round-the-clock staffed incident response

This is an important distinction. A system can collect data and generate alerts around the clock. That does not automatically mean a person is handling every alert around the clock.

The organisation therefore needs to be clear about:

  • when monitoring takes place
  • when alerts are generated
  • who receives them
  • during which hours incident response is available
  • which alerts should be escalated outside normal hours

This is particularly important for critical services. Otherwise both customer and provider may believe the other party holds a responsibility that was never actually agreed.

Alert fatigue is a real problem

If a system sends 150 disk warnings, 40 CPU alerts, 30 service-unavailable messages that clear after 20 seconds and another 80 informational messages, people start filtering mentally. Eventually the important alert is missed.

Thresholds therefore need calibrating. A three-second CPU spike probably should not alert. High CPU for 20 minutes combined with increased response times probably should. It is about finding relevant deviations, not the maximum number of notifications.

Correlation can reduce the noise

Imagine a switch fails. That can generate alerts for 20 access points, four servers, 15 network devices and a range of services. But the underlying incident is simply that the switch is down.

Modern monitoring tools support events, tags and correlation, which can be used to structure problems and notifications. Good monitoring therefore tries to help the human understand what the root problem is, not just how many things are red.

Monitor what is about to become a problem too

Monitoring does not only have to be about something being broken. It can also detect trends:

  • disk space is shrinking by 10 GB a week
  • the certificate expires in 21 days
  • backup volume is growing faster than storage
  • CPU usage has increased every month
  • the WAN link is approaching its capacity ceiling

That gives the organisation a chance to act before the incident happens. This is often where proactive monitoring delivers most value.

Monitor the backup

Backup is a good example. The questions can be:

  • Did the job run?
  • How long did it take?
  • How much data was copied?
  • Has the volume changed unexpectedly?
  • Is there sufficient storage capacity?
  • Has a job failed several days in a row?

But as we wrote in our insight on Microsoft 365 backup and recovery, a green job is not enough. The restore needs testing too.

What should management see?

Management does not normally need a technical dashboard with 300 metrics. More relevant questions are:

  • How available are our critical services?
  • Which recurring problems do we have?
  • Where are the capacity risks?
  • How quickly are incidents detected?
  • How quickly are services restored?
  • Which major deviations require a decision or investment?

That translation is what turns monitoring into management information.

Seven questions for a better monitoring model

  1. Which services are most critical?
  2. Which technical dependencies do they rest on?
  3. Which metrics show real impact?
  4. When should a metric become an alert?
  5. Who is responsible for each type of alert?
  6. When should an alert be escalated to an incident?
  7. How is the history used for improvement and capacity planning?

Once those questions are answered, choosing the tooling becomes considerably easier.

How Kristensson i Skåne can help

Kristensson i Skåne helps organisations establish and manage monitoring of servers, networks, cloud environments, applications, databases, websites, APIs, backup, and availability and performance. We work with Zabbix among other tools and can also integrate other data sources and cloud platform monitoring.

Support can include:

  • current-state analysis
  • implementation
  • triggers and thresholds
  • dashboards
  • alert flows
  • escalation model
  • reporting
  • capacity follow-up
  • ongoing management

The goal is not to produce the most graphs. The goal is for the organisation to detect the right problems before users have to tell you something is broken.

Frequently asked questions

What is the difference between monitoring and incident management?

Monitoring detects and signals deviations. Incident management is the process for analysing, prioritising and resolving the event.

What can Zabbix monitor?

Zabbix can collect data from many types of systems using items, use triggers for problem detection, actions for response and various channels for notifications.

Does every alert need to reach a human?

No. A good model filters and prioritises so that relevant problems reach the right recipient, rather than sending every notification to everyone.

Is IT monitoring the same as security monitoring?

No, but the areas overlap. Performance and availability are one perspective; logs and security events are another.

Want to know what actually needs monitoring in your environment? Read more about our monitoring services for businesses or contact us for an informal conversation.

Sources: Swedish National Cyber Security Centre (NCSC), 10 recommended security measures, measure 1 on ensuring the ability to detect security events; Zabbix documentation on items, triggers, actions and notifications. Verified 9 September 2026.

This text is general information. The right monitoring model always depends on the individual environment and the requirements of the business.