Observability
What is Observability?
Observability is the ability to understand what is happening inside a software system from the data it produces, such as logs, metrics and traces, so teams can diagnose problems they did not anticipate.
Updated November 2026 · 5 min read
Modern software is built from many services running on shared cloud infrastructure, talking to each other over networks and depending on third-party APIs. When something goes wrong, the cause is often several steps away from the symptom: a slow checkout page might be caused by a database lock in a service three calls away. Traditional monitoring, which checks predefined conditions such as CPU use or error counts, tells teams that something is wrong but often not why. Observability aims to answer the why. It is less about having more dashboards and more about being able to explore data freely when something unexpected happens. It means instrumenting systems so thoroughly that engineers can ask new questions of the data and trace a problem to its source, even if nobody anticipated that failure.
The term comes from control theory, where Rudolf Kálmán described in 1960 how well a system's internal state can be inferred from its outputs. In software, it gained wide use in the late 2010s with the rise of microservices and cloud-native systems. OpenTelemetry, an open standard created in 2019 by merging two earlier projects under the Cloud Native Computing Foundation, has become the common way to collect telemetry data. For SRE teams, developers, platform teams and incident responders, observability is the foundation for running complex systems reliably.
Definition of Observability
Observability is a property of a software system and the practices that support it, whereby the system emits rich telemetry, including logs, metrics, traces and events, that allows engineers to understand its internal state, investigate unexpected behavior and answer new questions without deploying new code.
It provides the data behind service level objectives (SLOs), supports incident management and has a specialized form for AI applications in LLM observability.
The Three Pillars and Beyond
Metrics are numerical measurements over time, such as request rates, error rates and latency. They are efficient to store and good for dashboards and alerts.
Logs are timestamped records of events, such as errors or user actions. They provide detail but can be expensive to store at scale.
Traces follow a single request as it moves through many services, showing where time is spent and where failures occur. They are essential in distributed systems.
Many practitioners now add events, profiles and other signals, and emphasize connecting all of them so engineers can move from a metric spike to the related traces and logs in a few clicks.
Observability vs Monitoring
Monitoring watches for known problems, such as a disk filling up or an error rate crossing a threshold. It answers questions decided in advance.
Observability supports investigating unknown problems, letting engineers ask new questions of the data during an incident.
The two work together. Monitoring and alerting tell teams when something is wrong, and observability helps them find out why. High-cardinality data, such as request and customer identifiers, is often what makes observability possible, since it allows engineers to narrow problems to specific users or requests.
Importance of Observability in Delivery and Engineering Operations
Observability shortens incidents. Engineers can find the cause of a problem faster, which reduces downtime and customer impact.
It supports frequent change. Teams that can see the effects of each release quickly can deploy more often with confidence.
It also improves understanding of systems. Traces and metrics reveal performance bottlenecks and unexpected dependencies that are hard to see in code alone. It improves collaboration, since shared data gives developers, operations and support teams a common view during investigations.
Observability and Financial Management
Faster diagnosis reduces outage costs, including lost revenue and engineering time spent on incidents.
Telemetry data can be very expensive to collect, store and query, and observability costs often grow faster than infrastructure costs. Managing retention, sampling and data volume is essential.
Observability data can also reveal inefficient services and wasted resources, supporting cloud cost optimization.
Standardizing on open formats such as OpenTelemetry reduces dependence on a single vendor and keeps options open as needs change.
Common Challenges
Collecting everything creates huge volumes of data and costs without making problems easier to find.
Inconsistent instrumentation across services, such as different log formats and missing trace context, makes it hard to follow requests end to end.
Teams with dashboards nobody looks at, or alerts that fire constantly, have data but not observability. Sensitive data, such as personal information, can leak into logs and traces, so data handling rules need to apply to telemetry too.
How to Build Observability
Building observability involves instrumenting services consistently, connecting signals, focusing alerts on user impact, managing data costs and building the habit of using the data.
The aim is not to collect the most data but to answer the questions engineers need answered during incidents and improvements.
Instrumenting Systems
Adopt a standard such as OpenTelemetry for metrics, logs and traces across all services, ideally built into the internal developer platform.
Propagate trace context through every service call, so requests can be followed end to end.
Use structured logs with consistent fields, such as request and user identifiers, so logs can be searched and linked to traces. Add business context, such as customer tier or feature name, so engineers can see which users are affected.
Using and Managing the Data
Base alerts on SLOs and user-facing symptoms rather than on every internal metric.
Set retention and sampling policies by data type and importance to keep costs under control. Keep full detail for errors and slow requests, which are the data engineers most often need.
Practice using the tools outside incidents, such as in reviews of performance or releases, so engineers are fluent when it matters. Review observability spending regularly, comparing data volumes with how often each type of data is actually used.
Examples of Observability in Practice
The examples below show observability in practice.
Both use illustrative figures. The first speeds up diagnosis, and the second controls data costs.
In each, better telemetry changed how teams worked.
Speeding Up Diagnosis
A ride-hailing company's incidents take an average of 90 minutes to diagnose, mostly spent searching logs across services. Engineers often have to ask several teams to check their own logs before the cause is found.
It adds distributed tracing to its 60 services and links traces to logs and metrics in one tool.
Average diagnosis time falls to 25 minutes, and engineers can see which service caused a slowdown within minutes.
Controlling Data Costs
A software company's observability bill has tripled in a year as it added services and verbose logs. Engineers estimate that most of the stored logs are never searched.
It reduces debug logging in production, samples traces for healthy requests while keeping all traces for errors and shortens retention for low-value logs.
Costs fall by 45% with no loss of the data engineers actually use during incidents.
Conclusion
Observability is the ability to understand what is happening inside a system from the data it produces, especially metrics, logs and traces. It goes beyond monitoring by allowing engineers to investigate problems nobody anticipated.
In delivery and engineering operations, observability shortens incidents, supports frequent change and improves understanding of systems. Instrumenting consistently with open standards, connecting signals, alerting on user impact, managing data costs and practicing with the tools help organizations run complex systems reliably.
Related terms
Service Level Objectives (SLOs)
Reliability targets, like 99.9% of requests succeeding over 30 days.
Incident Management
Detecting, responding to and resolving outages, then learning from them.
Internal Developer Platform
The self-service tools developers use to build, deploy and run software.
On-Call
Rotating responsibility for responding to incidents outside working hours.