A platform team cannot tell which of its capabilities are used, by whom, or whether they are working. What telemetry does a platform need about itself?

What a platform needs to know about itself

• Usage per capability, per consuming team. Aggregate usage hides that everyone uses one thing and nobody uses the other five — and it is the precondition for every deprecation decision. "Which teams call this" must be answerable in minutes.
• Version distribution across the estate: which template version, which library version, which base image. A long tail of very old versions is the earliest signal that propagation is not working, and it becomes visible long before it becomes a security problem.
• Success and latency of platform operations — provisioning, deployment, build — with the same rigour a customer-facing service would get, because consumers experience these as the platform's reliability.
• Support load split by category, because a high rate of "how do I" questions is a documentation and abstraction problem and a leading indicator of eventual bypass.
• Resource consumption and cost per consuming team, which is what makes quotas enforceable and noisy neighbours identifiable during an incident rather than afterwards.

Why usage telemetry is the highest-value item

Every subsequent platform decision depends on it. What to deprecate, what to invest in, who to talk to before a change, whether an improvement was adopted, and whether the platform's roadmap matches its consumers' needs.

A platform without it operates on anecdote, and its deprecations break unknown consumers.

What it must not become

A surveillance mechanism. Telemetry about how teams use the platform is legitimate; telemetry framed as measuring team productivity destroys the relationship the platform depends on, and it will be resisted and gamed.

The distinction is whether the data is used to improve the platform or to assess the teams, and the platform team's behaviour on that establishes it quickly in either direction.

The organisational payoff

It converts platform roadmap arguments into evidence. "Three teams use this and forty use that" ends a prioritisation discussion in a way that no amount of advocacy does — and it is usually a day of instrumentation away.