# Observability without drowning in dashboards

> More dashboards do not make a system easier to run — they make it easier to miss the one thing that matters. What to actually monitor, and what to ignore.

*Source: https://www.lazlosoftwaresolution.com/resources/observability-without-drowning-in-dashboards*

It is easy to confuse having dashboards with being able to run a system. A wall of graphs feels reassuring right up until something breaks and you realise none of them told you, because the one signal that mattered was buried under forty that did not.

Good observability is not about seeing everything. It is about noticing the right things quickly, and being able to reconstruct what happened afterwards.

## Alert on symptoms, not causes

Alert on what the user actually experiences: requests failing, responses getting slow, a queue backing up past the point of recovery. Those are symptoms, and they are what matter. Alerting on every possible cause produces noise, and noise trains people to ignore alerts — which is worse than having none.

## Every alert must be actionable

If an alert fires and the right response is to close it and move on, it should not be an alert. Each one should mean "a human needs to do something now." The fastest way to make on-call miserable, and to make people miss the real incident, is a stream of alerts that cried wolf.

 - **Metrics** for the health of the system — error rate, latency, saturation.

 - **Logs** you can search, so you can answer "what happened to this request" after the fact.

 - **A small number of alerts** that each demand action.

## Logs are for the questions you have not thought of yet

Dashboards answer questions you anticipated. Logs answer the ones you did not — and during an incident, those are the ones you have. The value is in being able to search them and follow a single request through the system, not in how many you collect.

> The measure of observability is not how much you can see. It is how fast you can answer "what is wrong, and what happened."

## Start small and add on evidence

You do not need to monitor everything on day one. Start with the few signals that tell you the system is healthy, and add more only when a real incident shows you a blind spot. Observability built this way stays useful. Observability built by adding every possible metric becomes the thing you have to ignore to get anything done.