Platform engineering metrics that actually prove ROI

This is a sponsored article brought to you by Spacelift.

Eighteen months ago, a platform team got funded. New hires, a tooling budget, and a mandate to fix the mess of scripts and tribal knowledge that hold the infrastructure together. This week, someone in leadership asked the obvious question: Is it working?

The honest answer, in a lot of organizations, is a shrug dressed up as a slide. Ticket counts are down. Nobody’s quite sure why. Deployment counts are up. Nobody’s sure that’s good news either, since more deployments could mean more automation or just more chaos moving faster.

This is a platform engineering measurement problem, and it’s as much a purchasing problem as an operational one. A platform team, or the tooling underneath it, gets funded on a promise: developers move faster, infrastructure gets safer, costs come down. Eighteen months later, renewing that investment requires proving the promise held. Most organizations discover at that exact moment that they never agreed on what “working” would look like.

Why the wrong metrics get tracked

The default metrics are the ones that are easy to pull, not the ones that answer the question leadership is actually asking. Ticket volume tells you how many requests came in, not whether developers are still waiting on infrastructure to ship something. Deployment count tells you how often something changed, not whether those changes are reliable, fast, or expensive to maintain. Uptime alone tells you the platform didn’t fall over, which is table stakes, not proof of value.

The deeper issue is that these numbers are properties of the tool, not the organization using it. A dashboard that shows “1,200 runs this month” is trivia unless it’s tied to what those runs cost, how long developers waited for them, and how many required human intervention. Without that context, a platform engineering investment is nearly impossible to defend in a budget review and nearly impossible to improve, since nobody can tell which lever actually moves the number that matters.

The four categories that actually matter

Organizations that get this right tend to track four categories of metrics, not one. Each answers a different question a buyer or a board member would actually ask.

Developer experience answers “did this make my engineers’ lives better.” The benchmarks worth aiming for: environment provisioning taking 10 minutes or less for the median request and under 20 minutes for the slowest 10%, feedback on a change arriving within 5 minutes, developers touching three tools or fewer to ship a change, and a self-service rate of 90% or higher, meaning nine times out of ten a developer gets what they need without opening a ticket to a human.

Adoption and usage answers “are people actually using this, or working around it.” Look at deployment frequency (healthy teams ship a median of two or more times per week), the share of active developers using the platform day to day (95% or higher in a mature setup), documentation coverage (90% or higher), and paved path adoption, meaning the percentage of new infrastructure that goes through the sanctioned templates rather than a one-off workaround (75% or higher is a reasonable target).

Reliability and performance answers “can I trust this when it matters.” Platform uptime during business hours should sit at 99.9% or better. Mean time to recovery for a P1 incident should be under 60 minutes. Change failure rate, the share of deployments that cause an incident or need a rollback, should stay under 10%.

Business value answers the question the CFO actually cares about: infrastructure cost per service trending down roughly 10% a quarter, idle spend capped at 15% or less of total spend, and lead time for changes measured in hours, not days. That last one is the number that most directly translates platform engineering into a business result that a non-technical stakeholder can understand.

From fragmented to standardized, without the big rewrite

Most organizations that end up with hundreds of Terraform projects and no shared standard didn’t plan for that. Every team solved its own problem with its own script, its own state backend, its own approval process, and none of it was wrong in isolation. The mistake shows up later, when someone tries to answer a simple question, like which environments touch a particular database, and finds six different ways teams have chosen to answer it, none of which are documented the same way.

The transition to a unified operating model rarely succeeds with a single rewrite, and treating it as such is a common way these efforts stall. Organizations that pull it off start with the highest-volume or highest-risk cluster of workspaces, the ones generating the most incidents or consuming the most manual review time, and build one paved path for that cluster: one module registry, one policy set, one way to request access. The rest migrates gradually, as teams touch their own infrastructure anyway, rather than through a forced migration that stalls the day someone hits a deadline.

That gradual approach also directly answers the evaluation question. When shortlisting a platform to centralize on, the four metric categories above aren’t just something to measure after the fact; they’re the criteria. Does the platform make self-service and paved-path adoption the default, or does it require a team to build that layer from scratch on top of it? Does it enforce policy natively, or does policy enforcement become another custom project bolted on afterward? Those questions separate a platform that will actually reduce fragmentation from one that just adds a seventh way of doing things to the six already in use.

What good looks like when it works

These aren’t hypothetical targets. One payments company scaled its infrastructure operations from a handful of deployments a day to an average of more than 500 a day, without a corresponding rise in incidents, once it had governance and defined workflows in place, rather than relying on ad hoc scripts. That kind of jump shows up in any organization that moves from letting each team invent its own process to standardizing hundreds of infrastructure workspaces under a single set of guardrails.

The pattern across all of them is the same: the metrics didn’t improve because someone tracked them harder. They improved because the underlying platform made the good path the default path: self-service instead of tickets, policy enforced automatically instead of remembered by a reviewer, and drift caught on a schedule instead of discovered in an incident. Measurement came second. The mechanism came first.

Buy the mechanism, don’t build the dashboard

This is where many platform engineering initiatives quietly go wrong. A team recognizes it needs these numbers, then spends the next two quarters building a custom dashboard to pull them out of five different tools that were never designed to talk to each other. The dashboard becomes the deliverable instead of the platform improvement.

The more direct path is to choose infrastructure orchestration tooling that produces these numbers as a side effect of how it works, rather than as a separate reporting project. When self-service is the built-in deployment path rather than a workaround, the self-service rate is already sitting in a dashboard that the platform ships with.

When policy as code gates every change automatically, the change failure rate reflects it from day one. When drift detection runs on a schedule instead of getting discovered during an incident, mean time to recovery drops because there’s no discovery phase at all.

That’s the question worth asking when shortlisting a platform: does it offer self-service infrastructure with guardrails built into the workflow itself, or does governance get added on top later?

Spacelift is built around the first version, pairing self-service templates with policy enforcement, audit trails, and drift detection in the same pipeline a developer already uses, which is what turns the benchmarks above into numbers a platform already produces rather than a reporting project a team has to build.

None of this makes the case for tracking more metrics. It makes the case for tracking the four that map to a real business question and for choosing a platform where the mechanism that produces good numbers is the same one developers already use to get their work done. That’s the difference between a platform engineering investment you can defend in eighteen months and one you’re still trying to explain.