Observability
Observability is the property of a system that lets a team ask new questions about its behaviour from the outside, through the logs, metrics and traces it emits, without already knowing what to look for, so it can explain something that went wrong in a way nobody predicted or wrote a check for in advance.
Submit a project See LLM observability and monitoringReviewed by Huy Nguyen (David), CEO · Updated 28 Oct 2026 · 5 min read
This term is one of the entries in the OutsourcingVN glossary of words buyers meet while planning how a live system is watched.
Why does observability matter?
A system can run known checks for the failures a team already anticipated, but a genuinely new failure, one nobody wrote a check for, needs a different kind of evidence to explain. OpenTelemetry's own documentation describes the distinction this way: "Observability lets you understand a system from the outside by letting you ask questions about that system without knowing its inner workings," and that "it allows you to easily troubleshoot and handle novel problems, that is, 'unknown unknowns'." OutsourcingVN is operated by Netbase JSC, and the reason a buyer should separate this from a simple uptime check is that observability depends on what was captured before the question was asked: if a system was not instrumented to emit the right logs, metrics and traces, no amount of dashboard-building after the fact can answer a question the data was never collected to support.
What is an example of observability in practice?
A checkout feature starts failing for a small slice of customers, but every existing alert, built around known failure modes such as a payment timeout or a full inventory table, stays green. An engineer with access to a trace of each failing request can follow one request's full path: which service it touched, how long each step took, and which step returned an unexpected result, without having anticipated this particular failure in advance. That trace, combined with the request's metrics and logs, is what lets the engineer form and test a new hypothesis about a cause nobody had written a dedicated check for, rather than simply confirming a check that already existed.
What are the common misreadings of observability?
Observability is not simply a bigger dashboard or more alerts: the Google SRE book describes monitoring as "collecting, processing, aggregating, and displaying real-time quantitative data about a system," built to answer "what's broken, and why?", while observability specifically adds the capacity to investigate a symptom nobody defined a check for beforehand. The CNCF glossary states the property plainly as "a system property that defines the degree to which the system can generate actionable insights," which is a property of how a system was built and instrumented, not a tool a team buys after the fact. Nor is observability a single kind of data: OpenTelemetry lists traces, metrics and logs among the signals it supports and notes that grouping signals lets a team observe the same piece of technology under different angles, so a system producing only one of them can answer only the questions that one signal covers.
Plan the next step for your project
Common questions
OpenTelemetry names traces (the path of a request through an application), metrics (a measurement captured at runtime) and logs (a recording of an event) among the signals it supports, alongside baggage.
The Google SRE book defines monitoring as collecting and displaying real-time quantitative data about a system so it can say what is broken and why; OpenTelemetry describes observability as what lets a team handle novel problems, the "unknown unknowns", using the signals a system was built to emit.
Only for the next incident. OpenTelemetry's primer says that to ask those questions "your application must be properly instrumented", so the code must emit the signals going forward; a trace, metric or log that was never captured cannot be recovered after the fact.
Which decisions does observability affect?
Planning which signals an AI-specific feature needs beyond these general ones is covered by LLM observability and monitoring, while the discipline of naming an owner and rehearsing a response once a signal crosses a threshold is set out in software reliability and incident readiness; managed operations is where this becomes a standing, operated discipline rather than a one-time build. The threshold a team agrees to for how quickly it must respond is usually written into a service level agreement. When you know what a live feature of yours would need to explain about itself, describe it and Netbase will respond through Netbase's own outsourcing-services platform; submit a project when you are ready.