What is Deployment Frequency? | DevOps Dictionary

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}")

PLACEMENT PRO TIP
**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 THIS
**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.

COMMON MISTAKE / WARNING
**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 / WARNING
**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