Observable by default

What this means in practice

Design and operate APIs so that healthy behaviour and failure modes are visible without special effort. Every API should emit the core telemetry needed to understand performance and reliability, and every request should be traceable end-to-end. Observability is part of the API contract: teams should be able to answer what is happening, why it is happening, and what to do next using metrics, logs, traces, and Service Level Objectives (SLO).

Why this matters

If teams cannot see what an API is doing, teams cannot operate it safely. Good observability shortens incident resolution, improves reliability, and reduces time spent guessing. It also enables better product decisions by making usage, performance, and failure trends measurable. Symptom-driven alerting helps teams catch real customer impact rather than noise from infrastructure signals.

Practices that meet this principle

• Expose core metrics for every API (for example: latency, error rate, throughput, saturation)

• Emit structured logs with consistent fields and sensible redaction

• Record and link a trace for each request that goes through multiple services, so teams can follow one request end-to-end

• Assign and propagate a correlation ID for every request, and include it in logs and response (for example in headers) where appropriate

• Define SLOs per Endpoint based on customer-visible outcomes (for example: availability, latency, error rate)

• Drive alerts from symptoms and SLO burn rates, not from infrastructure thresholds

Validation

A project meets this principle when:

• Teams can quickly answer what is failing and who is impacted using metrics, logs, and traces

• A single request can be followed end-to-end using correlation IDs and distributed tracing

• SLOs exist per API and are reviewed, with alerts aligned to SLOs and customer symptoms

• Logging and metrics are sufficient for triage without adding new instrumentation during incidents