ChatGPT
Claude
PerplexityAnswer five questions before reading anything else. Each one has a published reference value, and together they place your team against the rest of the market.
- How long does a change take to go from committed to running in production?
- How often do you deploy?
- When a deployment fails, how long until service is restored?
- What share of your deployments need immediate intervention?
- What share of your deployments are unplanned, triggered by something breaking in production?
Hold those answers. The rest of this page supplies the numbers to check them against, and explains why two of the five are almost impossible to measure with Salesforce’s native tooling.
DORA measures five delivery metrics, and Salesforce documentation still teaches four
Most Salesforce delivery advice cites “the DORA four keys.” That model is retired.
DORA’s current guidance states plainly that it has identified five software delivery performance metrics, split across two categories. Throughput holds change lead time, deployment frequency, and failed deployment recovery time. Instability holds change fail rate and deployment rework rate.
Two changes produced that structure. In 2023, mean time to recover was renamed and redefined as failed deployment recovery time, because the old definition failed to separate a failure caused by a software change from one caused by a data center outage. In 2024, DORA added deployment rework rate, the share of deployments that are unplanned and happen because something broke in production. The reasoning is worth keeping: change fail rate had been serving as a rough proxy for rework, and DORA decided rework deserved its own number.
One detail catches people who assume the categories are intuitive. Recovery time sits under throughput, not stability. DORA groups by what the metric describes about flow rather than by whether it sounds like a reliability measure.
Now compare that to what Salesforce publishes. Salesforce’s own DevOps metrics explainer still describes DORA metrics as a set of four, naming deployment frequency, lead time for changes, change failure rate, and mean time to recovery, and offering time to market as a sometimes-fifth metric that DORA has never used. Neither failed deployment recovery time nor deployment rework rate appears anywhere on the page.
The date is the part worth noting. That page carries a last-modified date of 28 August 2026, twelve days before this article was written, and still teaches the model DORA revised in 2023 and extended in 2024. This is not a neglected corner of the site. It is current documentation carrying a superseded framework.
DevOps Center measures three of the five, which caps what a Salesforce team can benchmark
The gap is not only editorial. It is built into the tooling.
Salesforce Help’s page on measuring project performance with DORA metrics states that DevOps Center supports promotions to production, average lead time from first commit to final promotion, and change failure rate, described verbatim as the percentage of promotions that failed or required a fix.
Map those three onto DORA’s five and the shortfall is specific:
| DORA metric | Measurable in DevOps Center |
|---|---|
| Deployment frequency | Yes, as promotions to production |
| Change lead time | Yes, as average lead time |
| Change fail rate | Yes |
| Failed deployment recovery time | No native equivalent |
| Deployment rework rate | No native equivalent |
Both missing metrics are the ones that describe what happens after a bad deployment. A Salesforce team using only native tooling can see how fast it ships and how often it breaks something, and cannot see how long the breakage lasts or how much of its next release is repair work.
Salesforce does publish prescriptive guidance on the same page, and it is the closest thing the vendor offers to a cadence recommendation: if change failure rate increases, improve testing and perform smaller, more frequent promotions. The page also advises monitoring trends over a period such as the last 30 days rather than reacting to single-day spikes. It attaches no target number to either instruction.
Reference values place a Salesforce team against the wider market
The Elite, High, Medium and Low labels most teams still quote do not appear in DORA’s current research. DORA has not announced their retirement, so the accurate statement is narrower: the word Elite appears nowhere in the 2025 report, which instead groups respondents into seven team archetypes derived from eight factors including burnout and friction rather than delivery speed alone.
Those archetypes are not a scoring instrument. The distribution tables are. Drawn from 4,867 respondents in DORA’s most recent annual report, they show where teams actually sit on each metric. DORA labels the running column Top %, accumulating from the highest-performing band downward.
| Change lead time | Share at this level | Cumulative |
|---|---|---|
| Under one hour | 9.4% | 9.4% |
| Under one day | 15.0% | 24.4% |
| One day to one week | 31.9% | 56.4% |
| One week to one month | 28.3% | 84.7% |
| One to six months | 13.2% | 98.0% |
| Deployment frequency | Share at this level | Cumulative |
|---|---|---|
| On demand, multiple per day | 16.2% | 16.2% |
| Hourly to daily | 6.5% | 22.7% |
| Daily to weekly | 21.9% | 44.6% |
| Weekly to monthly | 31.5% | 76.1% |
| Monthly to six-monthly | 20.3% | 96.4% |
| Failed deployment recovery | Share at this level | Cumulative |
|---|---|---|
| Under one hour | 21.3% | 21.3% |
| Under one day | 35.3% | 56.5% |
| One day to one week | 28.0% | 84.5% |
Change fail rate clusters between 8 and 16 percent, where 26 percent of respondents sit, and the cumulative share at 16 percent or better is 62.2 percent. Rework rate clusters in the same band, with 26.1 percent between 8 and 16 percent.
Read those tables honestly and most teams discover they are median rather than laggard. A team deploying weekly with a one-week lead time sits inside the largest group on both measures, which is a more useful finding than being told it is not Elite.
Salesforce delivery clusters at weekly rather than trailing the market
Cross-industry numbers only take a Salesforce team so far, because the platform ships three seasonal releases a year and much of the work is metadata rather than code.
Gearset’s State of Salesforce DevOps 2026, published 29 April 2026 from 522 quality-controlled responses, supplies the platform-specific values. One disclosure belongs with every citation of it: 48 percent of respondents were Gearset customers, a material selection effect in a survey about tooling adoption.
Asked how frequently the organization releases to production, Salesforce teams answered multiple times a day at 6 percent, daily at 6 percent, multiple times a week at 23 percent, weekly at 25 percent, multiple times a month at 24 percent, monthly at 9 percent, and multiple times a year at 7 percent.
Two derived figures matter, and they point in opposite directions. 12 percent deploy daily or more often, against 22.7 percent in DORA’s cross-industry distribution. 60 percent deploy weekly or more often, against 44.6 percent cross-industry.
So the common claim that Salesforce delivery is simply slower is wrong. Salesforce teams are roughly half as likely to reach daily deployment and meaningfully more likely to hold a weekly cadence. The distribution is tighter, not lower. Gearset’s own reading matches: release frequency continues to follow a bell curve centered on weekly and multiple times a week, with no significant shift toward daily deployment compared with the previous year.
On defect rates, 39 percent of Salesforce teams report bugs in under 5 percent of releases and 38 percent report between 5 and 10 percent, which leaves 23 percent shipping bugs in more than one release in ten. On recovery, 63 percent restore normal service within six hours of a production incident.
One caution before anyone builds a slide from a side-by-side. Gearset asks how long a feature takes to reach production after it has been built. DORA asks how long from commit to production. The Gearset lead time figures, 19 percent under a day and 38 percent between a day and a week, describe a narrower window and are not directly comparable.
Rework hours quantify what weak delivery practice costs per year
The most useful number in the 2026 Salesforce data is not a rate. It is an hours figure, and it converts delivery maturity into something a finance conversation can hold.
Gearset segments teams by how many of the six lifecycle stages they have both tooling and process for, then reports annual rework and downtime.
| Measure | Low adopters, 0 to 2 stages | Partial, 3 to 4 | High, 5 to 6 |
|---|---|---|---|
| Average annual rework hours | 155.1 | 81.2 | 68.7 |
| Average annual production downtime hours | 237.0 | 104.5 | 91.8 |
| Teams with error rate under 5% | 25.4% | 38.2% | 44.7% |
| Teams restoring production in under 6 hours | 47.0% | 55.0% | 69.8% |
A low-adoption team burns 86 more hours of rework and 145 more hours of downtime each year than a high-adoption team.
Read those four rows as the weakest-sourced numbers on this page, because they are. The word rework appears exactly once in the whole report, as the chart label. Gearset publishes no definition of a rework hour, no method for deriving downtime hours, and no sub-sample size for any of the three adoption tiers, while publishing totals for its other charts. A 522-person sample split three ways could leave the high-adoption cell small. The direction is credible and the decimal places are not.
The distribution matters as much as the totals. Gains do not stop at partial adoption. Teams that cover five or six stages keep improving over teams that stop at three or four, which argues against the common decision to tool the build stage and leave operate and observe uninstrumented.
Testing bottlenecks rank as the top blocker to scaling delivery
Asked to name the biggest blockers to scaling Salesforce delivery, 452 respondents selected testing bottlenecks, described as manual effort or slow feedback, more often than any other option: 173 selections, or 38.3 percent. Complex cross-cloud dependencies followed at 35.4 percent, skills and capacity gaps at 32.1 percent, governance slowdowns at 31.4 percent, and sandbox and production drift at 30.8 percent. Merge conflicts and overwritten work reached 29.9 percent.
Gearset reads its own data cautiously, noting that no clear leader emerges among the blockers, and the spread supports that. Testing is first by count rather than first by a margin that settles the question.
That ranking matches what practitioners describe. An r/salesforce thread from 2 April 2026 titled around developers overriding each other’s code drew 44 comments against only 5 upvotes, a ratio that usually marks a nerve rather than a broadcast. The author reported using DevOps Center for deployment and falling back to change sets when it failed, which the author said was often. The highest-scoring reply, at 35 upvotes against a next-best of 18, reframed the problem in one line: that is a devops problem, and specifically the lack of a devops practice.
The remedies split cleanly across existing disciplines. Testing throughput belongs to a Salesforce test strategy and regression testing that catches silent breakage. Environment drift belongs to sandbox strategy. Repair work that never gets scheduled accumulates as technical debt.
Well-Architected defines healthy cadence qualitatively rather than numerically
Salesforce does describe what good delivery looks like, in the application lifecycle management patterns under Well-Architected’s Resilient dimension. Each entry names a product area, a place to look, and the condition to check.
Five of those patterns are worth auditing against directly, and all five are checkable in an afternoon. Deployment history shows clear release cadences and fairly uniform deployment clusters within release windows. Deployment logs show no failed deployments within the available history. Change sets are not used to release changes. Risky configuration changes are never made directly in production. No releases occur during peak business hours.
No thresholds appear anywhere on that page. Salesforce says deploy more often, calls uneven deployment clustering a departure from the pattern, and publishes no number for either. That gap is why this page exists, and it is why a Salesforce team benchmarking itself has to borrow DORA’s distributions and platform-specific survey values rather than reading a figure from the vendor.
Where agents move the numbers, and where they do not
GetGenerative.ai runs Salesforce delivery through pods where a Forward Deployed Engineer leads and six purpose-built agents (Discovery, Metadata, Design, Build, Test and Support) carry production work across a six-stage sequence from discover to deploy. The relevant question for a benchmark page is which of the five metrics that actually moves.
Change lead time and deployment frequency respond to agent capacity. Both are gated by how quickly designs, configuration, code and test cases get produced. That is generation work, and it is the part that compresses.
Change fail rate and rework rate respond to review capacity, not generation. Producing more changes faster raises the volume needing judgment. The 12-year minimum experience floor GetGenerative.ai sets for its FDEs exists for that side of the equation rather than the first.
Failed deployment recovery time barely responds at all. Recovery depends on rollback design, environment strategy and who is on call at the time. No agent shortens it materially, and claiming otherwise would fail against the data on this page.
Two of five improve through throughput, two through supervision, and one is largely outside the model. Testing sits at the intersection, which is why the Test Agent matters more than its position in the list suggests: testing bottlenecks are the top-ranked blocker in the market, and they gate lead time and change fail rate simultaneously.
The honest limitation is measurement rather than capability. Because DevOps Center captures no recovery or rework metric, a team adopting any AI-led delivery model, ours included, cannot demonstrate improvement on two of the five without instrumenting them separately. Establish the baseline before the engagement starts, or the benchmark becomes an argument rather than a number. If you want that baseline captured as a defined exercise, talk to us about a delivery assessment.
Your scorecard, filled in
| Metric | Cross-industry median band | Salesforce-specific value | Native Salesforce measurement |
|---|---|---|---|
| Change lead time | One day to one week (31.9%) | 38% take a day to a week post-build | Yes, commit to promotion |
| Deployment frequency | Weekly to monthly (31.5%) | 60% weekly or better, 12% daily or better | Yes, as promotions to production |
| Change fail rate | 8 to 16% (26.0%) | 23% ship bugs in over 10% of releases | Yes |
| Failed deployment recovery | Under one day (56.5% cumulative) | 63% restore within six hours | No |
| Deployment rework rate | 8 to 16% (26.1%) | Not separately published | No |
Sources: DORA 2025, n=4,867; Gearset State of Salesforce DevOps 2026, n=522 with 48% Gearset customers; Salesforce Help, DevOps Center DORA metrics.
Where this leaves you
DORA measures five delivery metrics. Salesforce’s own documentation still teaches the retired four-metric model, and DevOps Center instruments three, leaving recovery time and rework rate invisible to teams on native tooling alone. Salesforce delivery is not slower than the wider market so much as tighter: fewer teams reach daily deployment, more hold a weekly cadence. Weak lifecycle coverage is reported to cost roughly 86 extra rework hours and 145 extra downtime hours a year. Testing is selected as a blocker more often than anything else.
What delivery leads ask about these numbers
How often should a Salesforce team deploy to production?
No Salesforce-published number exists. The platform ships three seasonal releases a year, and Salesforce advises smaller, more frequent promotions without setting a target. Survey data shows 60 percent of Salesforce teams release weekly or more often and 12 percent daily or more often, so weekly is the modal cadence rather than a standard.
What is a good change failure rate for Salesforce?
Among Salesforce teams, 39 percent report bugs in under 5 percent of releases and 38 percent report 5 to 10 percent. Cross-industry, the largest cluster sits between 8 and 16 percent. Under 5 percent puts a Salesforce team in the leading group; above 10 percent puts it in the trailing 23 percent.
Why does DORA now have five metrics instead of four?
Mean time to recover was renamed failed deployment recovery time in 2023, because the original definition did not separate failures caused by a change from failures caused by infrastructure. Deployment rework rate was added in 2024, since change fail rate had been acting only as a proxy for how much repair work teams absorbed.
Can DevOps Center measure all the DORA metrics?
No. DevOps Center reports promotions to production, average lead time from first commit to final promotion, and change failure rate. It has no native equivalent for failed deployment recovery time or deployment rework rate, so a team wanting to benchmark those two must instrument them separately.
What does poor delivery practice actually cost per year?
Gearset reports that teams with tooling and process for two or fewer of the six lifecycle stages average 155.1 rework hours and 237 production downtime hours annually, against 68.7 and 91.8 for teams covering five or six. That is a gap of roughly 86 rework hours and 145 downtime hours, though Gearset publishes no definition of a rework hour and no per-tier sample size.
