Platform Engineering Observability

Platform Observability

Measuring the health, adoption, and impact of the developer platform itself — through platform SLOs, DORA metrics, golden path adoption tracking, and developer satisfaction signals — so the platform team can operate and improve the platform with data.

⏱ 10 min read

What it is

Platform observability applies the same principles of metrics, logging, and alerting to the platform itself that application teams apply to their services. The platform team must measure two categories: platform health (is the platform working as intended — are CI pipelines succeeding, is environment provisioning completing in time, is Backstage available, are Kubernetes operators reconciling correctly?) and platform impact (is the platform actually improving engineering outcomes — are deployment frequencies increasing, are lead times decreasing, is developer satisfaction improving?). Without platform observability, the platform team is flying blind: they cannot prove value to leadership, cannot detect platform degradation before developers are impacted, and cannot prioritise improvements based on evidence.

The four DORA metrics (from the DevOps Research and Assessment programme, now part of Google Cloud) are the industry standard for measuring software delivery performance: Deployment Frequency (how often the organisation deploys to production), Lead Time for Changes (time from code committed to running in production), Change Failure Rate (percentage of deployments that cause a production incident or require rollback), and Mean Time to Restore (time to recover from a production incident). DORA research shows these four metrics are positively correlated with both organisational performance (profitability, market share, productivity) and employee well-being. The platform team's primary long-term impact is improving these four metrics for all teams building on the platform.

Why it exists

Platform teams frequently struggle to justify continued investment to engineering leadership because their value is diffuse — they do not ship customer features, and their impact is spread across many product teams. Without data, the platform team cannot demonstrate that CI pipeline improvements reduced deployment lead time by 40% across 20 teams, or that the self-service database provisioning eliminated 300 infrastructure tickets per year. Platform observability provides the evidence base for these claims, enabling the platform team to operate as a genuine product team with a data-driven roadmap rather than as a best-effort infrastructure group that reacts to the loudest complaints.

Additionally, the platform is infrastructure that other teams depend on. When the platform is degraded — an operator that is stuck in a crash loop, a CI pipeline template with a broken step, Backstage returning 503s — product team deployments may be blocked silently. Platform SLOs with alerting ensure the platform team is notified of degradation before product teams are impacted, rather than learning about it through frustrated Slack messages.

When to use

  • Implement platform health SLOs and alerting for every platform component that product teams depend on (Backstage, CI runners, Kubernetes operators, ArgoCD) — this is a prerequisite for the platform team to operate as a reliable infrastructure provider.
  • Instrument DORA metrics for all product teams from the first week of platform operation — baseline data is invaluable for measuring improvement.
  • Track golden path adoption metrics whenever a new template or workflow is launched — adoption rate at 30 / 60 / 90 days determines whether the template solved the right problem.
  • Run developer satisfaction surveys quarterly and correlate satisfaction scores with platform usage data to identify which platform investments are having the most impact.
  • Create per-team DORA dashboards shared with engineering managers — teams that can see their own metrics are more motivated to improve them.

When not to use

  • Using DORA as performance management: DORA metrics are team-level indicators of process health, not individual performance metrics; using them to evaluate individual engineers creates perverse incentives (small, trivial PRs to inflate deployment frequency).
  • Optimising a single metric: Optimising for deployment frequency alone (without measuring change failure rate) encourages reckless deployments; always track all four DORA metrics together as a balanced scorecard.
  • Dashboard-only observability: Dashboards that nobody reviews provide no value; every platform metric should have an owner and a review cadence; connect metrics to platform team sprint planning.

Typical architecture

Platform Observability Stack
──────────────────────────────────────────────────────────
  DORA Metrics Pipeline
  ├── Deployment Frequency
  │   Source: GitHub Actions workflow completions
  │           (deploy job on main branch)
  │   Collector: GitHub → Prometheus pushgateway
  │   Dashboard: Grafana (per-team, org-wide)
  │
  ├── Lead Time for Changes
  │   Source: commit SHA timestamp → deploy timestamp
  │   Collector: CI pipeline events → BigQuery
  │   Dashboard: Looker Studio (trend over time)
  │
  ├── Change Failure Rate
  │   Source: PagerDuty incidents tagged with deploy SHA
  │           or manual incident tracking
  │   Dashboard: Grafana (rolling 30-day %)
  │
  └── Mean Time to Restore
      Source: PagerDuty incident open → resolved time
      Dashboard: Grafana (per-team, p50/p90)

  Platform Health SLOs
  ├── Backstage availability: 99.5% (alerts at <99%)
  ├── CI pipeline success rate: >95% (alerts at <90%)
  ├── CI p50 duration: <12 min (alerts at >20 min)
  ├── Kubernetes operator reconcile: 0 error rate
  │   (alerts if any operator in CrashLoopBackOff)
  └── Environment provisioning SLA: <10 min

  Adoption Metrics (Backstage Analytics + GitHub)
  ├── Monthly active portal users
  ├── % new services created via golden path template
  ├── % services with catalog-info.yaml (catalog coverage)
  └── Developer NPS / SPACE survey scores (quarterly)

Pros and cons

Pros

  • DORA metrics provide an objective, research-backed framework for communicating platform impact to engineering leadership in business terms.
  • Platform health SLOs with alerting ensure the platform team detects and responds to degradation before product teams are blocked.
  • Adoption metrics identify which platform investments are actually being used versus which are well-engineered but unused, enabling better roadmap prioritisation.
  • Per-team DORA dashboards create healthy transparency and enable teams to track their own improvement over time.
  • Baseline DORA data collected before major platform investments provides a counterfactual for proving improvement attributable to the platform.

Cons

  • DORA data collection requires integration with multiple systems (GitHub, CI, PagerDuty, deploy tooling) that may not be available or consistent across all teams.
  • Change failure rate measurement requires reliable incident-to-deploy correlation, which is difficult in organisations without a mature incident management process.
  • Dashboard proliferation — a platform team with 15 dashboards and no review process gains false confidence; regular dashboard review rituals are necessary.
  • Survey fatigue reduces developer survey response rates below statistical significance if surveys are too frequent or too long; keep surveys short (10 questions max) and quarterly.
  • DORA metrics can be gamed by teams that understand how they are measured; focus on trends over time rather than absolute values, and supplement with qualitative developer interviews.

Implementation notes

For DORA metrics: start with deployment frequency and lead time for changes as these have reliable, automatable data sources (CI/CD pipeline events). Use a dedicated DORA data pipeline: instrument GitHub Actions workflows to emit deployment events (service name, commit SHA, timestamp, environment) to a Prometheus pushgateway or directly to a time-series database; compute lead time by joining deploy events with commit timestamps from the GitHub API. Tools such as Four Keys (Google's open-source DORA implementation) or LinearB/Haystack provide managed DORA measurement if the engineering data team is not available to build the pipeline.

For platform health SLOs: define SLIs (Service Level Indicators) for every platform component that product teams depend on. For Backstage: HTTP availability (% of health check requests returning 200) and API latency (p95 of catalog API response time). For CI: pipeline success rate and duration. For Kubernetes operators: number of operators in CrashLoopBackOff (should be zero). Create Grafana dashboards with threshold alerts that fire to the platform team's on-call rotation — not just to a channel where messages are ignored. Establish a platform incident severity taxonomy (S1: Backstage down; S2: CI failure rate >15%; S3: operator degraded) and respond accordingly.

Common failure modes

  • Measuring deployment frequency without context: Team deploys 10x per day but all deployments are hot-fixes for a high change failure rate; deployment frequency looks great, platform health is poor; always track deployment frequency alongside change failure rate.
  • MTTR measurement gaps: Organisation has no formal incident management process; MTTR cannot be measured because incident start and end times are not recorded; invest in PagerDuty or equivalent with mandatory incident lifecycle tracking before relying on MTTR data.
  • Platform health SLO without pager: Platform SLO is defined in Grafana but alerts fire to a Slack channel where they are ignored; the platform team learns about Backstage being down from product team complaints 3 hours later; all SLO breach alerts must go to on-call with an SLA for acknowledgement.
  • Adoption metrics hiding quality issues: 80% adoption of the golden path template is celebrated; nobody checks the 20% who did not adopt; investigating reveals the template does not work for Java 21 services, affecting the platform's newest tech stack; adoption rate requires root-cause investigation of non-adoption.
  • DORA as a blame tool: Engineering manager compares team DORA scores publicly and uses low scores as a performance indicator; teams with complex domain problems (database migrations, regulatory releases) have structurally lower deployment frequency; DORA is most useful for tracking a single team's improvement trend, not for cross-team comparison.

Decision checklist

  • Are DORA metrics (all four) instrumented and reviewed at least monthly by the platform team and shared with engineering leadership?
  • Does every critical platform component (Backstage, CI, operators, ArgoCD) have defined SLIs, SLOs, and alerting that pages the platform on-call?
  • Is golden path adoption rate tracked per template and reviewed after each new template launch?
  • Is developer satisfaction measured quarterly (SPACE survey or NPS) with results feeding directly into the platform roadmap?
  • Are per-team DORA dashboards available to engineering managers for their own teams?
  • Is there a regular platform metrics review ritual (weekly or bi-weekly) where the platform team reviews health and adoption data?

Example use cases

  • Proving platform ROI to leadership: Platform team collects 6-month baseline DORA data before launching new CI pipeline templates; after launch, deployment frequency increases from 2 per week to 8 per week across 15 teams; lead time drops from 3 days to 4 hours; change failure rate is stable at 5%; platform team uses this data to justify growing from 4 to 7 engineers.
  • Detecting platform degradation proactively: Kubernetes database operator has a memory leak after a new version rollout; operator begins failing after 6 hours uptime; platform health alert fires 8 minutes after the first reconciliation failure; platform on-call rolls back the operator version before any product team database provisioning is blocked.
  • Using adoption data to fix broken golden paths: Java 21 services template shows 40% adoption vs 85% for Python; investigation reveals the Java template generates a Gradle wrapper with a security vulnerability that the security scanner blocks; template is fixed and re-validated; Java adoption rises to 78% over the following quarter.

Further reading