← Back to principles

Platform

Make Observability a Built In Capability

Statement

Make Observability a Built In Capability

What this means in practice

Logging, metrics, and tracing are provided by default so teams can understand system behaviour, diagnose issues, and improve their software in real time. Observability is embedded into the platform rather than left as an afterthought for individual teams to implement independently. Standard tooling and conventions ensure consistency across services.

Why this matters

Built-in observability gives teams immediate insight into how their systems behave in production, reducing mean time to detection and resolution. Without it, teams build bespoke monitoring in isolation, leading to inconsistent coverage, blind spots during incidents, and slow diagnosis. Observability as a platform capability raises the baseline for all teams and supports a culture of data-driven improvement.

Practices that meet this principle

  • Logging, metrics, and distributed tracing are available out of the box for all platform-hosted services

  • Standard observability tooling and dashboards are provided and maintained by the platform team

  • Conventions for structured logging, metric naming, and trace propagation are defined and documented

  • Alerting capabilities are available for teams to configure against their own service-level objectives

  • Observability data is accessible to delivery teams for debugging, performance analysis, and improvement

Validation

A project meets this principle when:

  • Services emit structured logs, metrics, and traces without requiring bespoke setup by the delivery team

  • Standard dashboards and alerting are available and in use

  • OR:

  • Observability coverage extends across all platform-hosted services, not just a subset

Scoring Guide

  • Score −1 — Disagreement / Rejected: The team acknowledges this principle is applicable but has explicitly decided not to follow it for this product. A rationale and decision record exist explaining why built-in observability is not adopted.

  • Score 0 — Not doing: No standard observability tooling or conventions. Teams build bespoke monitoring independently (or not at all). No structured logging, metrics, or tracing in place. Blind spots during incidents are common.

  • Score 1 — Planned: The team has committed work to make observability a built-in capability. An owner and target date exist for introducing standard logging, metrics, tracing, and dashboards. The plan is tracked.

  • Score 2 — Adopted for new work: All new services emit structured logs, metrics, and traces using platform-provided tooling. Standard conventions for logging, metric naming, and trace propagation are documented and applied. Dashboards and alerting are available for new services. Any exceptions are explicit and reviewed.

  • Score 3 — Enforced for new work + migration plan: Built-in observability is systematically enforced for all new work through process or tooling (e.g. automated instrumentation, deployment gates requiring observability). A tracked migration plan exists to extend observability coverage to legacy and existing services.

  • Score 4 — Fully adhered: Observability is comprehensive across all platform-hosted services including legacy. Standard dashboards and alerting are in active use. Teams can diagnose production issues using platform tooling without additional instrumentation. Alerting is configured against service-level objectives. Remaining gaps are minimal, known, and time-bound.