---
# source: src/content/services/en/monitoring.md
# route:  /en/services/monitoring/
title: Monitoring
group: support
order: 3
tags: [monitoring, managed-services]
summary: Every system can raise an alert. The skill is relating them to each other rather than receiving fifty messages for one outage.
photo: monitoring-wall
photoNeed: "A monitoring dashboard at 2am tone: dark room, one screen, one person"
stub: false
draft: false
---

## The actual problem

Every product, hardware and software alike, can send alerts. That is precisely the
difficulty: in a single outage the host, the storage, the database and the application all
speak up at once, and in that volume the one message naming the cause gets lost.

## What a monitoring estate has to do

It is made of senders and receivers, and its job is correlation: relating messages to each
other so that fifty events become one incident. Only then is analysis possible at all.

## Two kinds, and both are needed

**Availability monitoring** answers whether something is running. It reports the outage.

**Performance monitoring** answers how well it is running. It reports the trend leading to
the outage, and is therefore the half that prevents one.

Run only the first and you reliably learn that something is broken. Run both and you learn
it beforehand.

## What to watch

An alert nobody acts on is worse than no alert: it trains the team to ignore messages.
Before rollout, settle which message reaches whom and what happens next.