Dora NodaWeave Intelligence surveyed 518 platform engineers for its 2026 State of Platform Engineering Report, Volume 4, and asked how they measure whether their platform is working. The single largest identifiable answer, after DORA metrics (40.8%), was "we do not measure" — 29.6% of respondents, larger than SPACE (14.1%) and every other named framework combined. Nearly a third of platform teams have no answer to "did this work?" beyond a shrug.
That's the headline. The more useful part of the report is everything it shows about why that number holds steady even as platform engineering itself has gone mainstream — and what a team building its own internal platform, especially on self-hosted infrastructure, should track from day one instead of ending up in that 29.6%.
What the Vol 4 Survey Actually Found
The report's numbers, straight from the source, sketch a discipline that's institutionally arrived but operationally unproven:
- 55.9% of organizations now run more than one internal platform — multiple platforms are now the norm, not a sign of fragmentation.
- Annual budgets are thin relative to scope: 47.4% of platform initiatives run on $0–$1M/year, 25.8% on $1–5M, 12.2% on $5–10M, and the remaining 14.5% split across $10M–$100M+ tiers. Nearly three-quarters of platform initiatives operate under $5M.
- Time to demonstrate value is bimodal: 35.2% show measurable value within six months (13.1% within three), but 40.9% either take more than a year or still can't measure it at all — including an 18.3% slice that reports no measurable results, period.
- On the AI side, Vol 4 itself found 94% of organizations see AI as critical or important to platform engineering's future and 75% are already hosting or preparing to host AI workloads. A separate, larger 2026 survey — Perforce's State of DevOps: Platform Engineering Edition, 820 professionals — found 73% of platform teams have folded an AI assistant into at least one developer workflow. Two different surveys, same direction: AI adoption is outrunning platform measurement discipline.
None of this is a story about platform engineering losing momentum. Gartner's oft-cited 2026 forecast — 80% of large organizations will have a dedicated platform team, up from roughly 45% three years ago — lines up with what Vol 4 shows on the ground. The gap is narrower and more specific: adoption solved, proof unsolved. Widely cited alongside that same forecast is the flip side of it: fewer than 30% of those teams will show a measurable developer-productivity gain from the initiative. Momentum without proof is exactly the setup that produces a 29.6% "we don't measure" answer.
"We Don't Measure" Is a Budget Symptom, Not an Oversight
It's tempting to read the measurement gap as a maturity lag — teams too busy shipping to instrument anything. Vol 4's own adoption data says something less charitable: most platforms aren't earning their usage, they're being pushed onto it.
Asked why users adopt the platform, respondents split four ways: 36.6% said adoption is "driven by extrinsic push, often mandated," 16.9% called it "erratic, with no coherent strategy," 28.2% reported genuine intrinsic pull, and 18.3% described participatory adoption where users contribute back. Add the first two together and 53.5% of platforms are used because someone was told to, not because the platform earned it — more than half, against 46.5% with some form of organic buy-in. That split shows up again when Vol 4 asks platform teams to name their biggest challenge: "driving developer adoption / overcoming cultural resistance" tops the list at 45.3%, ahead of establishing a shared product vision (44.3%) and the complexity of existing systems (43.9%). Proving ROI sits lower, at 25.9% — teams are more worried about getting used than about proving the value of being used.
Now put that next to the budget data. Nearly half of platform initiatives run on $0–$1M a year, and another quarter on $1–5M — money that has to be re-justified against a competing claim on the same engineering budget every planning cycle. A platform that's mandated onto developers rather than pulled in by them is, by definition, one where usage numbers alone don't prove value; a team can point to high adoption and still be describing compliance, not demonstrated productivity. Combine mandate-driven usage with "we don't measure," and a platform team's renewal case is two unverified claims stacked on top of each other.
Vol 4's own author's-note aside makes the same point more bluntly: 29.6% say they don't measure, yet only 24.2% say they don't know whether metrics have improved — a "5% delta of liars," in the report's words, describing teams that apparently do have a sense of impact but chose not to report measuring it. That's not a data problem. It's a team that has decided measurement isn't worth the political exposure of a bad number — precisely the posture that gets a line item cut in a budget review 12–18 months later.
The Three Metrics Worth Instrumenting From Day One
None of the fixes here require a dashboard vendor or a quarter of tooling work. Three metrics, cheaply instrumented from the day a platform team stands up, cover the two questions that actually get asked in a budget review — "is this faster than before?" and "are people actually choosing to use it?" — plus the one question 2026's AI-in-the-loop platforms specifically need answered.
Time-to-first-deploy. The interval from a new developer's (or new service's) first git push against the platform to the first successful HTTPS response from the resulting deployment. Instrument it with two timestamps: capture T0 off the inbound webhook that triggers a build, and T1 off the first passing health check against the live endpoint. Log T1 - T0. Mature platforms report this in the range of an hour to a day; ad hoc infrastructure reports it in weeks. It's the single number that best captures whether "self-service" is real or theoretical, and it requires no new infrastructure — every platform already has both timestamps somewhere in its logs.
Self-service rate. The share of infrastructure requests — new database, custom domain, scaling change, secret rotation — resolved without a support ticket. Formula: self-service completions ÷ (self-service completions + tickets filed for the same request category). This is the number that directly answers Vol 4's adoption-mandate finding: a platform with a rising self-service rate is one developers are choosing over the ticket queue, not one they're routing around toward a mandated path with no better option. Instrumenting it just means tagging every request-handling code path (API call vs. ticket) with a category and counting both sides.
Agent-completed-task rate. With 73–75% of platform teams already running AI agents against infrastructure, "did the agent's change stick" is now as load-bearing as "did the human's change stick" — and it's the metric least likely to already exist anywhere in a platform's tooling. Define it as the share of agent-initiated changes (a PR, a deploy, a scaling action) that land without a human revert or manual follow-up commit within a fixed window, say 24 hours. Formula: agent actions that stuck ÷ total agent actions attempted. A platform team running this number gets an early warning the moment agent-driven changes start requiring more cleanup than they save — before that shows up as a budget-review question about whether the AI investment paid off.
Wiring These Into a Self-Hosted, Cluster-API Stack
The concrete version of this, on infrastructure a platform team actually owns rather than a vendor's managed service, looks like three cheap hooks rather than a new subsystem.
For time-to-first-deploy: a Git provider's push webhook already carries a timestamp; a Cluster API-managed fleet's ingress controller already logs the first 200 on a newly provisioned route. Diffing those two timestamps for every new App-style custom resource — the object a platform like Bex.co creates per deployed service — costs one log-correlation job, not a new pipeline.
For self-service rate: every API call against the platform's control plane (create database, attach domain, rotate credential) is already an audited action if the platform logs API requests at all, which any Cluster API-based control plane does by default for its custom resources. Tag each category, count support-ticket volume for the same category from whatever ticketing tool the team already runs, and divide. No new instrumentation — just joining two logs that already exist.
For agent-completed-task rate: an agent operating a self-hosted PaaS through its API — merging a PR that changes a bex.yml, or calling the deploy endpoint directly — leaves the same audit trail a human operator does. Tag those actions by actor (agent vs. human) at the point they're already logged, then watch the revert/follow-up window. A platform built with AI agents as first-class operators from the start, rather than bolted on after the fact, gets this distinction for free instead of as a retrofit.
None of these three metrics require adopting a full DORA or SPACE program before a platform team ships anything. They're the minimum viable instrumentation — cheap enough to wire up in the same sprint the platform goes live, and specific enough to answer the exact two questions ("is it faster," "is it chosen") that separate the 35.2% of initiatives showing value in six months from the 40.9% still guessing after a year.
The Choice Vol 4 Actually Describes
Vol 4's own framing is that platform engineering has moved from an emerging discipline to "the foundational operating system of the modern enterprise" — adoption is no longer the open question. What's still open, eighteen months into a typical platform initiative's funding runway, is whether the team running it can answer "did the platform work" with a number instead of a shrug. The 29.6% who can't aren't a fringe case; they're the modal failure mode of the entire discipline in 2026, and the fix costs three log-correlation jobs, not a quarter of tooling investment.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with AI agents as first-class operators from day one. If your platform's next budget review needs a number instead of a vibe, star the repo on GitHub and start measuring from the first deploy.
