What should a platform team measure about its own platform, and what is most often missing?

What to measure

Platform health: - SLO attainment per capability, separately for control plane and data plane. - Error rates and latency for platform APIs, segmented by consuming team. - Provisioning success rate and time-to-provision. - Deployment success rate and rollback frequency.

Consumer experience — the category most often missing: - Time-to-first-success for a new team, which is the single best proxy for developer experience. - Voluntary adoption rate, the honest indicator of value. - Support burden per consuming team, which should fall as self-service improves. - Fleet-wide change reach — how long a platform change takes to reach the majority of services, measuring whether the platform can actually change anything. - Version spread across template and library versions, which is the leading indicator of the above.

Consumption: - Usage per capability per team, which makes deprecation possible and capacity planning real. - Cost attributed per consuming team. - Quota utilisation, so a team approaching a limit is warned rather than surprised.

What is most often missing

Per-consumer segmentation. Aggregate platform metrics are dominated by the many small consumers and are blind to the few large ones being completely broken — the same failure as any multi-tenant system, and it means the platform's dashboards report health while its most important consumers are struggling.

Alert on outliers, not on aggregates: "any consuming team whose provisioning latency exceeds N", rather than a fleet average.

The second gap

Measuring capability delivery rather than adoption. A platform reporting "twelve capabilities shipped" and not "three adopted" is measuring its own activity. Adoption is the success metric — a capability nobody uses has not been delivered, and the team is now maintaining it.