Observability

In one line

Observability is the property that lets you ask new questions of a running system without shipping new code — built from structured logs, metrics, and distributed traces, now standardised under OpenTelemetry.

Monitoring vs observability

Monitoring answers known questions ("is CPU above 80%?"). Observability lets you answer questions you didn't anticipate — "why is this clinic's lab feed slow only at 2pm?" — without shipping new code, by querying rich signals you already emit. In a system of many services, you can't predict every failure, so you instrument for the unknown.

The three signals

• Logs — structured events with context (not just text). What happened, with detail.
• Metrics — cheap numeric time series (request rates, latencies, error percentages), alertable via SLOs. How much, how often, trending.
• Traces — one request's journey across services, each hop a timed span. Where the time went — the tool that turns "the system is slow" into "this query in this service is slow."

OpenTelemetry gives vendor-neutral instrumentation; Prometheus/Grafana, Sentry and peers store and visualise.

The design rule

Instrument at build time. Bolting observability on during an incident is too late — you can only ask questions of signals you were already collecting. Treat it as a feature, not an afterthought.

Where it shows up in digital health

• The invisible failure — an interface engine silently dropping lab results is the classic one; observability makes it visible before a clinician notices a missing result.
• Uptime and error tracking are in this platform's launch gate.
• The PHI twist — logs in clinical systems may themselves contain PHI, so observability pipelines need the same privacy discipline (HIPAA/ DPDP) as the application. Scrub or tokenise sensitive fields.

Common pitfalls

• Logging PHI in plaintext — a compliance breach hiding in your debug logs.
• Alert fatigue — too many noisy alerts and the real one is missed (same failure mode as clinical alerts).
• Metrics without traces — you'll know that it's slow but not where; you need all three signals.

Key takeaways

• Observability lets you ask new questions of a live system — beyond pre-set monitoring.
• Three signals: logs (detail), metrics (trends/alerts), traces (where time goes).
• Instrument at build time; OpenTelemetry standardises it.
• In health, govern log PHI as carefully as the app — and avoid alert fatigue.