ObservabilitéJuly 27, 2026

Observability: connect technical signals to useful on-call action

Start with a user journey, define SLIs and SLOs, then page people only when there is a clear reason and response.

Collecting logs, metrics and traces does not guarantee that a team will understand its next incident. Observability becomes useful when signals answer two questions: are users affected, and who can act now?

OpenTelemetry describes traces, metrics and logs as complementary signals: request path, measurement over time and detailed event. Without stable service identity and shared conventions, collecting all three creates another silo.

Start with a user journey

Choose an important journey such as sign-in, payment, mobile synchronisation or file processing. Describe success, then define an SLI: successful requests, latency below a threshold or data freshness.

An SLO sets the target over a window. Google’s Implementing SLOs guidance asks product stakeholders, developers and production owners to agree the objective and error-budget policy. Copying a percentage from another service says little about your users.

Instrument the critical path

Propagate context across calls and correlate traces with logs. Start at boundaries: incoming request, dependency, database, queue and business outcome. OpenTelemetry zero-code instrumentation can provide a quick technical view on several runtimes, but meaningful business steps often need explicit code.

Review attributes before export. A trace identifier helps correlation; personal data and secrets do not belong in telemetry. Set retention and sampling according to diagnostic value and cost.

Page only when someone can act

Google's SRE chapter on monitoring distributed systems separates conditions that should interrupt a person from those that can wait. A page should indicate real or imminent impact and lead to a known response.

An alert should name the service, symptom, affected SLO, recent changes and first diagnostic step. If nobody can act, route it to a ticket or dashboard. Review alerts acknowledged without action; they consume attention without protecting users.

Begin with one journey, SLI, SLO, policy and alert. Review missed incidents, false positives and diagnostic quality. The goal is not to observe everything. It is to detect what matters and give the on-call engineer enough context to act.

Official sources

Share this article

Read also