Deployment Frequency

CI/CD hub

One of the four DORA metrics — measures how often an organisation successfully deploys to production. Elite performers deploy multiple times per day. High frequency is only safe with automated testing, fast rollback, and small batch sizes.

Deployment Frequency

Deployment Frequency is one of the four DORA metrics. It measures how often an organisation successfully deploys code to production. It is a speed metric — but only a meaningful one when paired with the stability metrics (Change Failure Rate and MTTR), since deploying often while breaking production often is not actually elite performance.

Why Frequency Matters

The core insight behind this metric is that smaller, more frequent deployments are inherently lower-risk than large, infrequent ones. A deploy containing three commits is far easier to reason about, test, and roll back than a deploy containing three hundred. Teams that deploy multiple times a day are, almost by construction, deploying in small batches — the high frequency is a symptom of good batch-size discipline, not a goal pursued for its own sake.

Benchmark Bands

◈ DIAGRAM

+------------------------------------------+
| Low: less than once per 6 months         |
+------------------------------------------+
                      |
                      v
+------------------------------------------+
| Medium: once per month to 6 months       |
+------------------------------------------+
                      |
                      v
+------------------------------------------+
| High: once per week to once a month      |
+------------------------------------------+
                      |
                      v
+------------------------------------------+
| Elite: multiple deploys per day          |
+------------------------------------------+

Tier	Deployment Frequency
Elite	Multiple deploys per day
High	Between once per week and once per month
Medium	Between once per month and once every six months
Low	Fewer than once every six months

A team at Swiggy shipping the food-ordering checkout service multiple times daily, each change small and independently tested, is the canonical elite-tier example this metric was designed to capture.

Blockers to High Frequency

Long test suites — if the full test suite takes 45 minutes, the pipeline itself caps how many deploys per day are even possible.
Manual approval gates everywhere — a human sign-off required for every environment, including low-risk staging deploys, adds latency that compounds across a day.
Large pull requests — a PR that takes two days to review is two days of code sitting un-deployed, batched up with whatever else lands in the meantime.
Coupled release trains — deploying ten services together as one release means the slowest or riskiest service caps the frequency for all of them.

Measuring Deployment Frequency

Pull successful production deploy events from your CI/CD platform or the GitHub Deployments API over a fixed window, then divide by the number of days in that window.

Bash

curl -s -H "Authorization: Bearer $GITHUB_TOKEN" \
  "https://api.github.com/repos/swiggy/checkout-service/deployments?environment=production&per_page=100" \
  | jq 'length'

Python

deploys_in_window = 47
window_days = 30
print(f"Per day average: {deploys_in_window / window_days:.2f}")

Tip
Measure deployment frequency per service, not as one number across an entire org. A platform with 40 microservices deploying once a week each can look like "weekly deploys" in aggregate while individual teams are actually shipping multiple times a day.

Remember
A high number here only means something good if Change Failure Rate is also low. Always read this metric alongside the other three DORA metrics, never alone.

Security
Higher deployment frequency means more frequent exposure of the deploy pipeline's credentials and permissions to automated execution. Make sure least-privilege scoping on runners and OIDC roles scales with frequency — a pipeline running ten times a day with over-broad permissions multiplies risk tenfold versus once a week.

Common Mistake
Artificially inflating deployment frequency by counting no-op or config-only deploys, or by deploying to a staging environment and counting it toward the production number. This produces a metric that looks elite on a dashboard while shipping nothing meaningfully faster.

Troubleshooting Reference

Symptom	Check	What to Look For
Frequency number looks too high	Filter deploys by `environment=production` only	Staging or preview deploys mixed into the count
Frequency stuck low despite small PRs	Time from PR merge to deploy job start	A manual approval gate or batching window delaying otherwise-ready changes
Frequency varies wildly week to week	Plot daily counts, not just the weekly average	Deploys batched right before a release freeze, then a long gap after

Frequently Asked Questions

What actually separates an 'elite' deployment frequency from a 'low' one in DORA's research?

DORA's State of DevOps research buckets performers into elite (on-demand, multiple deploys per day), high (between once per week and once per month), medium, and low (fewer than once per month). The gap isn't really about deploy scripts — it correlates strongly with batch size: teams deploying daily are shipping small, low-risk diffs, while monthly-deploy teams are bundling weeks of changes into one release, which is inherently riskier and harder to debug when something breaks.

Why can chasing higher deployment frequency backfire?

Frequency is one of four DORA metrics and is only a good sign paired with the others — change failure rate and mean time to recovery. A team that deploys ten times a day but rolls back six of them isn't actually elite; they're generating noise. Track deployment frequency alongside change failure rate from the start, not as a vanity number on its own, and make sure fast rollback and feature flags exist before pushing frequency up, not after.