What "Observability" Actually Means

Observability is one of those invented computer terms that looks misspelled at first glance. It's a useful word, though — some people even shorten it to o11y — and it describes something precise: the tools, data sources, and methods we use to understand how a system is operating.

In computer engineering, observability means the ability to observe. We don't say "observable tools" or "observable metrics" because that phrasing implies the wrong thing. It suggests some metrics are inherently visible and others are not, which misses the point. Observability is about what you can look at and what you choose to look at.

In practice, the term gets used in a few recurring ways:

  • "What observability tools are installed?" — What tools exist that only read state?
  • "What observability does that database have?" — What metrics, logs, and traces are exposed?
  • "How do you do observability?" — What products do you use to collect and view telemetry?
  • "Let me try some observability first." — Let me inspect the system without changing anything.

Observability vs. Experimentation

A common misconception is that every performance tool is an observability tool. Not so. Experimentation tools change the state of the system to learn about it. Benchmarks are the classic example: they load the system, alter its behavior, and measure the response.

An analogy helps: a car's dashboard is observability. Speed, RPM, temperature — these gauges let you see how the car is running without modifying it. A 0–60 mph test is an experiment; it changes the car's state to produce a measurement.

This distinction matters in practice. A performance consultant who gains access to production systems must know which tools only read state and which ones interact with it. Saying "I'll start with observability tools only" builds the trust needed to work on live, sensitive systems. It's a promise that nothing will be disturbed during initial investigation.

The Observer Effect Still Applies

Observability tools aren't perfectly harmless. Executing any tool consumes resources — usually a negligible amount, but sometimes enough to perturb the system under study. This is the observer effect: the act of measuring can influence what you're measuring. Understanding that risk is part of choosing the right tool and interpreting its results responsibly.

Use Both Hands

There's also a methodological point buried in the term: observability is a reminder to switch between categories of work. As one engineer put it, "You have two hands. Observability and experimentation." Sticking to one approach when diagnosing performance problems means working one-handed. Good troubleshooting requires both: first observe to form hypotheses, then experiment to test them.

Observability, in short, is the discipline of looking before touching — and using the right kind of look for the question you're asking.