Application teams say the platform is unreliable. The platform team's dashboard shows 99.95% on every component. How do you resolve this?

Both are right, and that is the finding

The platform measured its components. Consumers experience journeys. The gap between those two views is where trust erodes, and it is unproductive precisely because both sides have data.

Measure what consumers actually do

Replace component metrics with journey metrics, measured end to end from the consumer's request:

• Time to provision a new environment.
• Deployment success rate, first attempt.
• Pipeline queue time at the ninetieth percentile.
• Time to first successful deploy for a brand-new service.
• Success rate of a self-service infrastructure request.

Instrument these before discussing them. The conversation changes completely when the number is "deployments succeed first time 91% of the time, and on Fridays 78%" rather than "the platform feels flaky".

Expect to find the failure is in the seams

Individual components are usually fine. The failures are in composition: a token expiring between two stages, a race between provisioning and DNS propagation, a retry storm when a dependency is slow, a queue that only builds at a particular time of day. None of those appear in any component's own availability figure, and all of them are the platform team's responsibility because the platform is the composition.

Attach an error budget

Once journey SLOs exist, give them budgets. This does two things: it converts "unreliable" into a number both sides can plan against, and it gives the platform team legitimate grounds to stop taking feature requests when the budget is spent — which is usually the change that fixes the underlying problem, since the reliability work was being deprioritised against features.

The thing not to do

Do not argue with the perception using component numbers. It is technically correct and it will confirm to every application team that the platform team does not understand their experience — which is a more expensive outcome than the outage being discussed.