Deployment frequency is how often a team successfully releases code to production over a given period. It is one of the four DORA keys, and the only one that is a pure throughput measure: it says nothing about quality, speed per item, or recovery — just how often working software reaches real users.

It is also the DORA metric teams most often report wrongly, because the arithmetic is trivial and the definition is not.

How do you measure deployment frequency?

Count successful production deployments in a window and divide by the length of that window.

Deployment frequency = successful production deployments ÷ time period

Forty deployments across a four-week month is roughly ten a week, or about two a working day. DORA itself expresses the metric as a cadence band rather than a decimal — “on demand”, “weekly”, “monthly” — because the band is what distinguishes delivery models, not the second decimal place.

What is a good deployment frequency?

The 2024 State of DevOps Report was the last to publish the familiar four-tier model, and its thresholds are still the most widely quoted reference:

• Elite — on demand, multiple deployments per day.
• High — between once per day and once per week.
• Medium — between once per week and once per month.
• Low — between once per month and once every six months.

In that 2024 data roughly 19% of teams landed in the elite band. The more interesting movement was in the middle: the high tier shrank from 31% to 22% year over year while the low tier grew from 17% to 25%. The distribution was not improving.

Two caveats matter before you benchmark yourself against those bands. First, the tiers were never fixed cutoffs — they came out of cluster analysis on each year’s survey sample, so the boundaries drifted annually. Second, DORA’s 2025 research retired the low / medium / high / elite clustering altogether, replacing it with seven team archetypes defined by delivery performance and human factors such as burnout and organisational friction. Treat the four tiers as directional, not as a grade.

If you want a benchmark that survives team-size differences, LinearB’s 2026 engineering benchmarks normalise the metric per developer per week: above 0.2 is elite, 0.09 to 0.2 is strong, 0.03 to 0.09 is fair, and below 0.03 needs improvement. For a five-person team, “strong” is a deployment every two or three days.

What counts as a deployment?

This is where two teams with identical engineering practice end up reporting wildly different numbers. Settle these before you publish a figure, and write the answers down next to it:

• Production only. Staging and pre-production releases do not count, however well they rehearse the real thing.
• Successful only. A pipeline run that failed before reaching production is not a deployment. It may belong in your change failure rate conversation, but not in this numerator.
• Feature flags are not deployments. Shipping code behind a dark flag is a deployment; flipping the flag on later is a release event. Counting both double-counts the same change.
• Per service, not per repository. In a microservice estate, one service deploying twenty times a day will mask six services deploying monthly if you aggregate. Measure at the service level and roll up deliberately.

None of these has a universally right answer except the first two. What matters is that the definition is explicit, stable across reporting periods, and restated whenever the number is shown. A deployment frequency quoted without its definition is a number, not a metric.

Measuring deployment frequency in Jira

Worth being precise here, because it is a common source of confusion: Jira does not know about your deployments unless you tell it. Jira’s own releases and versions are a planning construct — a version can be marked released without a single line of code reaching production, and code can reach production without a version ever being cut.

What Jira Cloud does offer is a deployments feature that has to be switched on and fed. Connect a deployment tool — Bitbucket Pipelines, GitHub Actions, GitLab, Jenkins, Azure DevOps or another supported integration — and deployment events start appearing on work items, on board cards, in the releases hub, and on a deployments timeline. That page also surfaces deployment frequency as an insight. So the metric is available natively, but only downstream of a working CI/CD integration.

If that integration does not exist, the honest answer is that Jira cannot give you deployment frequency, and no amount of workflow reporting will conjure it. Issue transitions tell you when work was marked done, which is a flow metric, not a deployment record. That distinction is the same one that separates cycle time from lead time: what the clock starts and stops on decides what the number means.

Read it against the stability keys

Deployment frequency on its own is trivially gameable in the other direction from change failure rate: ship more, more often, and the number climbs regardless of whether any of it stayed up. The pairing is the point. DORA’s consistent decade-long finding is that throughput and stability do not trade off — teams that deploy more often tend to fail less often and recover faster — and a rising deployment frequency alongside a flat or falling failure rate is the signal worth chasing.

It is also the metric most distorted by process rather than engineering. DORA has repeatedly found that organisations with formal external approval processes are substantially more likely to sit in the low-performing band, and has found no evidence that change advisory board sign-off reduces change failure rate. If your deployment frequency is monthly, the constraint is often the gate, not the team.

For the wider picture and how the four keys fit together, start with our guide to DORA metrics in Jira, then read lead time for changes as the throughput key that answers “how long” rather than “how often”.

If you are measuring delivery flow in Jira today, Time in Status, Cycle Time & Lead Time Reports covers time in status, cycle time, lead time and throughput. The four DORA keys, deployment frequency among them, are on our roadmap rather than shipped today.

Frequently asked questions

What is a good deployment frequency?

Under the last published four-tier model, on-demand deployment — multiple times per day — was the elite band, once a day to once a week was high, and monthly or slower was low. DORA retired those tiers in 2025, so a more useful target is your own trend: frequency rising while change failure rate holds steady is improvement; frequency rising while failures climb is not.

How is deployment frequency calculated?

Divide the number of successful production deployments by the length of the period they occurred in. The arithmetic is simple; the accuracy depends entirely on agreeing what counts as a deployment — production only, successful only, and counted per service rather than per repository.

Is deployment frequency the same as release frequency?

Not quite. A deployment puts code into production; a release makes a change visible to users. With feature flags and dark launching the two come apart — code can sit deployed for weeks before it is released. DORA measures the deployment, not the announcement.

Can you measure deployment frequency without CI/CD?

You can count manually, but the number degrades quickly. Manual deployment logs go stale, disagree with each other, and rarely survive a team change. If deployments are not recorded by an automated system, treat any deployment frequency figure as an estimate and say so when you present it.