Deployment Frequency
How often you ship is the first number to fix.
Average days between deploys
—
Deploys per week
—
Intervals between consecutive deploys (days)
Your history
How this is calculated
From a list of deploys in your selected window, the calculator sorts timestamps,
computes the gap between each consecutive pair, and averages them. Deploys per
week is 7 / avg_days_between_deploys.
In “Count in window” mode, average days between deploys is days / deploys.
You need at least two deploys in the window to get a meaningful number.
Tiers
| Avg days between deploys | Tier |
|---|---|
< 0.5 | Elite Deploy on merge |
0.5 to 2 | High Daily cadence |
2 to 4 | Healthy Multiple per week |
4 to 7 | Weekly Steady weekly rhythm |
7 to 14 | Batch Manual gates or heavy QA |
> 14 | Traditional Waterfall-style release windows |
Why this matters
Deploy frequency is a proxy for batch size. A team shipping every three days cannot be carrying a branch that is a month old. They have already broken the work down and merged it behind feature flippers. A team that ships every three weeks is carrying that same batch around for three weeks, and every bug in it costs more to find.
Raising deploy frequency surfaces every upstream problem. Flaky tests stop being a nuisance and become a blocker. Manual QA steps stop being acceptable. What the number buys you is the pressure to make everything behind it better.
What to do next
- If your average is over 7 days, look at your last ten merged PRs and count the ones over 400 lines. Big PRs are usually the reason batches stay big.
- If CI takes more than ten minutes, fix that before anything else. Slow CI is a rate limiter on everything downstream.
- If your deploy step is manual, automate it to run on green main. You can still gate what reaches customers with feature flags.
- If you ship frequently but half your deploys cause problems, deploy frequency is misleading you. Run the Change Failure Rate calculator.