Accelerate State of DevOps Report 2024
Google Cloud / DORA, the program’s tenth report, 120 pages, read from the published PDF (v. 2024.3). Brought in by the 2026-08-12 research pass for growth edge 5 — which readiness items actually reduce incidents.
Tier T2, with the conflict stated. DORA is survey research with a published methodology chapter and uncertainty intervals on every estimate, which is why it is not T3. It is also published by a company that sells platform and AI tooling, and one of its findings here is unflattering to platform tooling — that cuts toward, not against, taking the numbers at face value.
What it measures and how
An annual worldwide survey of people in technical and adjacent roles, “augmented … with in-depth interviews … as a way to get deeper insights, triangulate, and provide additional context.” Performance levels come from cluster analysis — “We do not set these levels in advance, rather we let them emerge from the survey responses” — and estimates carry 89% uncertainty intervals.
The report says DORA “heard from more than 39,000 professionals” over its decade; the text read here does not state this year’s sample size separately, so treat 39,000 as the program total rather than the 2024 N.
The measure changed this year
Change failure rate had always been the odd one out: “strongly correlated with the other three metrics but statistical tests and methods prevent us from combining all four into one factor.” DORA’s hypothesis was that it proxies rework, so they added a question — “approximately how many deployments in the last six months were not planned but were performed to address a user-facing bug” — and confirmed it. The four keys are now five metrics on two factors:
- Software delivery throughput — change lead time, deployment frequency, failed deployment recovery time.
- Software delivery stability — change failure rate plus rework rate: “the likelihood deployments unintentionally lead to immediate, additional work.”
The 2024 clusters
| Level | Lead time | Deploy frequency | Change fail rate | Recovery | Share |
|---|---|---|---|---|---|
| Elite | < 1 day | on demand | 5% | < 1 hour | 19% |
| High | 1 day–1 week | daily to weekly | 20% | < 1 day | 22% |
| Medium | 1 week–1 month | weekly to monthly | 10% | < 1 day | 35% |
| Low | 1–6 months | monthly to half-yearly | 40% | 1 week–1 month | 25% |
Read the third column down the table: Medium’s change fail rate (10%) is better than High’s (20%). The report does not hide this — it says throughput and stability correlate within every cluster and that “factors besides throughput and stability influence cluster performance,” suggesting the medium cluster “may benefit from shipping changes more frequently.” It is a real dent in the tidy Elite→Low ladder dora-metrics describes, and worth carrying.
The finding this spoke did not want
89% of respondents use an internal developer platform (deliberately broad definition). Using one:
- individuals 8% more productive, teams performing 10% better, and organizational performance up;
- software delivery throughput down ~8% against non-users;
- software delivery stability down 14% — “the change failure rate and rate of rework are significantly increased when a platform is being used”;
- being required to use the platform exclusively for the whole app lifecycle: a further 6% decrease in throughput;
- and instability in combination with a platform is linked to higher burnout. DORA is careful: “That isn’t to say that platforms lead to burnout, but the combination of instability and platforms are particularly troublesome.”
DORA offers hypotheses rather than a cause. On throughput, an IDP adds handoffs between systems, each one “an opportunity for time to be introduced.” On stability, three readings are left open: the platform gives teams the confidence to ship more freely (so instability is a symptom of experimentation, not of damage); the platform is not actually ensuring change quality; or its automated testing runs only whatever tests the application already had.
AI, since the spoke keeps asking
For every 25% increase in AI adoption: organizational performance +2.3%, team performance +1.4%, product performance no obvious association. Separately, teams that shifted to adding AI-powered experiences to their service show a 10% decrease in software delivery stability than those that have not. The report’s own summary of the tension: AI adoption “significantly increases individual productivity, flow, and job satisfaction. However, it also negatively impacts software delivery stability and throughput.”
What it settles, and what it does not
It is the first source in this spoke to connect a platform-ops intervention to a measured delivery outcome, and the direction is against the spoke’s own thesis — see synthesis and internal-developer-platform.
It does not close growth edge 5. This is cross-sectional, self-reported survey data with an inferential leap from individuals to organizations that the report’s methodology chapter acknowledges. Nobody instrumented a readiness checklist, changed it, and measured incidents before and after. And its outcome is delivery stability, not incidents: change failure rate and rework are pipeline facts, whereas the edge asks about production.
Related
dora-metrics · internal-developer-platform · platform-engineering · production-readiness · service-level-objectives · aiops · platform-ops · synthesis