CI/CD Statistics (2026)

A CI/CD dashboard can show thousands of jobs, a high pass rate, and a busy engineering organization—without telling you how often code reached production. That distinction matters when you need a number for a planning document, budget case, or release-readiness conversation.

Here is the short answer: the most useful CI/CD statistics for 2026 come from several incompatible evidence types. Vendor telemetry measures activity on a specific platform; surveys measure what respondents report using; repository studies measure public codebases. Use the statistic whose population and metric match the claim you need to make.

Key CI/CD statistics for 2026

• CircleCI analyzed 28,738,317 workflows run in September 2025 from projects with at least two contributors and workflows run at least five times. In this CircleCI-only telemetry population, average daily workflow runs grew 59% year over year; the top 5% of teams grew 97%, the median grew 4%, and the bottom quartile showed no measurable growth. CircleCI’s February 2026 report summary is vendor telemetry, not an industry-wide CI/CD adoption rate.

• In that same September 2025 CircleCI population, 70.8% of main-branch workflows succeeded, and the typical team took 72 minutes to get back to green after a failure. CircleCI says the recovery figure was 13% higher than in the prior year; it is a platform-specific recovery measure, not a universal reliability benchmark.

• GitHub recorded 11.5 billion GitHub Actions minutes in public and open-source projects during 2025, a 35% year-over-year increase. GitHub separately reported that the Actions architecture powered 71 million jobs per day; the minutes figure excludes private and enterprise usage, while the jobs figure has a broader platform population. GitHub’s December 2025 Actions update reports both measures.

• GitHub reported 43.2 million pull requests merged per month on average and more than 986 million commits in its 2025 reporting period, with commits up 25% year over year. These are GitHub developer-activity measures, not deployment counts. GitHub’s 2025 Octoverse analysis supplies the platform figures.

• In JetBrains’ October 2025 CI/CD survey, 62% of respondents used GitHub Actions for personal projects and 41% used it in organizations. The same survey found 32% of organizations used two CI/CD tools and 9% used at least three. JetBrains’ survey write-up treats personal and organizational use as separate contexts.

• A March 2026 JetBrains article, citing the State of Developer Ecosystem Report 2025, reported organizational use of GitHub Actions at 33%, Jenkins at 28%, and GitLab CI at 19%; it also reported 55% of developers regularly use CI/CD tools. JetBrains’ 2026 analysis is a separate survey presentation, so its 33% figure should not be read as a trend against the October survey’s 41% result.

• Docker’s 2025 State of Application Development survey included more than 4,500 developers, engineers, and technology leaders in an online, 25-minute survey fielded in fall 2024. Respondents reported using GitHub Actions (40%), GitLab (39%), and Jenkins (36%). The options were not mutually exclusive, so these are reported tool-use rates rather than market share. Docker’s July 2025 report summary describes the sample and fieldwork.

• In GitLab’s 2024 Global DevSecOps Report, 67% of respondents described their software development lifecycle as mostly or completely automated, and 64% said they wanted to consolidate their toolchain. GitLab’s 2024 report is historical self-reported survey evidence, not a measure of automated pipeline steps in 2026.

• The CD Foundation’s 2024 State of CI/CD Report found 83% of developers reported involvement in DevOps-related activities. The study combined six Developer Nation surveys from Q3 2020 through Q1 2023 and more than 125,000 respondents worldwide. The CD Foundation report is a broad historical DevOps-involvement measure, not a current CI/CD adoption percentage.

• The 2024 empirical study Chronicles of CI/CD analyzed 612,557 GitHub repositories with more than 10 stars, sampled from 2012 through October 18, 2023. It found 200,023 repositories (32.7%) with at least one identified CI/CD technology; among those repositories, GitHub Actions appeared in 57.8% and Travis in 38.8%. The original research paper measures popularity-filtered public GitHub repositories, not companies or private enterprise environments.

Get the Mobile Testing Playbook Used by 800+ QA Teams

Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.

Email addressGet Instant Access

100% Free. No spam. Unsubscribe anytime.

What current CI/CD telemetry shows

CircleCI’s data is the closest thing in this set to an operational view of pipelines. It counts workflows that actually ran, rather than asking people what tools they use. That makes its figures useful for questions about activity, main-branch outcomes, and recovery within CircleCI’s ecosystem.

The 59% average growth figure needs its distribution attached. A typical CircleCI team grew workflow activity by 4%, while the top 5% grew by 97%. If you are describing the finding, say that activity was unevenly distributed in CircleCI’s September 2025 workflow population. Saying that “CI/CD teams ran 59% more workflows” turns a vendor average into a claim about the whole market.

The same discipline applies to pipeline health. A main-branch success rate describes the share of a defined set of runs that succeeded; time to get back to green describes recovery after a failing condition. Neither metric tells you change failure rate, production incident frequency, or deployment frequency unless the source measures those things directly.

For your own dashboard, keep success rate, pipeline duration, build time, failure rate, and recovery time separate. GitLab’s documentation defines pipeline metrics around total runs, median duration, success rate, and failure rate, while Spotify’s Backstage plugin exposes build time, pipeline duration, success rate, and error rate for a selected catalog entity. Those are local measurement definitions, not external benchmarks. GitLab’s metric documentation and Spotify’s CI/CD Statistics plugin show the practical vocabulary.

How CI/CD tool-use surveys differ

Tool-use surveys answer a different question from workflow telemetry: “What do people say they use?” That can reveal stack overlap and organizational preferences, but it cannot establish usage volume, pipeline quality, or a vendor’s market share.

JetBrains provides a useful example of why survey context belongs beside every percentage. Its October 2025 results split personal projects from organizational use, and its March 2026 article presents a different organizational table from a cited ecosystem report. The public pages do not establish whether wording, respondent filtering, or survey timing caused the 41% and 33% GitHub Actions figures to differ. Treat them as distinct observations rather than evidence of a rise or fall.

Docker’s results reinforce the overlap problem. GitHub Actions, GitLab, and Jenkins all appear near 40% in its survey because a respondent can use more than one tool. A company may run one tool for legacy services, another for cloud-native workloads, and a third for specialized deployment processes. The percentages therefore cannot be added to create a total, and they should not be ranked as though they were exclusive market shares.

If you are choosing a tool rather than citing a statistic, the decision requires capabilities, operating constraints, and existing code—not just a survey percentage. Our guide to CI/CD tools for developers addresses that decision separately from this statistics report.

Why GitHub activity is not deployment activity

GitHub Actions minutes, jobs per day, commits, and merged pull requests all describe real platform activity. They do not use the same unit, and none is automatically a production-release measure.

Actions minutes are compute time consumed by workflows. Jobs per day are executions handled by the platform architecture. Merged pull requests describe completed code-review events. Commits describe changes recorded in repositories. Each can be useful in a capacity or developer-activity discussion, but converting any of them into “deployments” would invent a relationship the source did not publish.

This is especially important for the public/open-source qualifier on GitHub’s 11.5 billion Actions minutes. That figure excludes private and enterprise usage. The 71 million jobs-per-day statement, meanwhile, is a broader platform architecture figure. They belong in the same picture of scale, but not in the same denominator.

For a release-readiness argument, connect CI/CD activity to a measure that actually tests the release path. For mobile apps, that often means adding device-specific checks to the pipeline; integrating mobile tests into CI/CD is a practical follow-on when that is your next question.

Historical CI/CD adoption baselines

The older sources are still useful when you label them accurately. GitLab’s 2024 survey captures respondents’ perceptions of SDLC automation and toolchain consolidation. The CD Foundation report captures developer involvement in broad DevOps-related work from a methodology window ending in Q1 2023. Neither is evidence that a fixed share of all organizations has adopted CI/CD in 2026.

The repository study is more concrete about its denominator: popular public GitHub repositories. Its 32.7% result means that 200,023 of the 612,557 repositories in the study had at least one identified CI/CD technology. It does not tell you how many organizations use CI/CD, how intensively they run it, or what happens inside private repositories.

That limitation is not a flaw in the research. It is a reminder to match the noun in your sentence to the denominator in the source. Write “repositories in the study,” “survey respondents,” or “CircleCI workflows,” rather than replacing them all with “companies” or “the industry.”

What public CI/CD statistics do not yet measure

The sources above offer workflow counts, tool-use responses, platform activity, and repository prevalence. They do not provide a comparable public measure of mobile real-device CI/CD reliability, hardware-only failure incidence, or time to surface a mobile regression.

No first-party Quash data covers those questions. Quash has not published telemetry, customer data, or a completed experiment that quantifies them, so this report cannot supply a number for them. A useful future study would run the same suite on real devices and emulators, define the failure classes in advance, and report the dated sample and outcomes.

That gap matters when a pipeline passes in a virtual environment but the release decision depends on physical-device behavior. It is also why a general pipeline success rate should not be used as proof of mobile release reliability. If flaky mobile checks are affecting your own delivery flow, start by measuring them as a distinct failure class; this mobile flaky-test diagnosis guide explains the investigation process.

Methodology and source notes

This report keeps five evidence types separate:

1. Vendor telemetry: CircleCI workflow observations and GitHub platform data.

2. Survey data: self-reported tool use or automation views from JetBrains, Docker, GitLab, and the CD Foundation.

3. Repository research: identified CI/CD technologies in a defined sample of public GitHub repositories.

4. Metric documentation: definitions that help you instrument your own CI/CD environment.

5. Named measurement gaps: questions that these public datasets do not answer, including mobile real-device reliability.

The report excludes unverified DORA delivery-performance figures and unsupported CI/CD market-size estimates. A precise but unsupported number is less useful than a narrower statistic with a clear population, period, and source.

Conclusion

The strongest CI/CD statistic is not necessarily the largest one. It is the one whose metric matches your claim: CircleCI workflow telemetry for platform operations, GitHub data for platform activity, surveys for reported tool use, and repository research for public-code prevalence.

When you cite a CI/CD number, carry its denominator with it. That lets your reader decide whether it applies to the pipeline, team, or release decision in front of them.