Observability
Logs, metrics and traces designed in from the start — so 'why is it slow?' has an answer instead of a war room.
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.
How it works
The three signals: logs (structured events with context), metrics (cheap numeric time series — request rates, latencies, error percentages — alertable via SLOs), and traces (one request's journey across services, each hop a timed span; 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 their peers store and visualise. Design rule: instrument at build time — bolting it on during the incident is too late.
Where it shows up in digital health
An interface engine silently dropping lab results is the classic invisible failure — observability is how it becomes visible before a clinician notices a missing result. Uptime and error tracking are in this platform's launch gate; the deeper health-IT twist is that logs in clinical systems may themselves contain PHI — observability pipelines need the same privacy discipline as the application.