Deployment Frequency measures how often production deployments occur in a selected period. It's one of the four DORA metrics and the simplest indicator of release cadence.
What it measures
Total production deployments per unit of time — typically per day, week, or month. Higher frequency generally signals smaller batches, better automation, and tighter feedback loops.
Where the deployment signal comes from
Leanmote can count deployments two ways, and you choose which one your organization uses:
Merged pull requests (default) — every pull request merged into a tracked repository counts as one deployment. Merging is a stand-in for shipping: it needs no CI/CD configuration, it works from the day you connect GitHub, and for teams that deploy on merge it tracks your actual release cadence closely.
GitHub deployments (opt-in) — Leanmote counts the production deployments recorded in GitHub for your repositories. This measures the release itself rather than the merge that preceded it, so it also sees deploys that no pull request explains: a rollback, a re-deploy of the same commit, a commit pushed straight to your main branch.
Already deploy on every merge? Then both sources will report similar numbers, and staying on the default is a perfectly good answer. Switching still changes two things: a merge whose deployment failed stops counting as something you shipped, and Change Failure Rate starts reading the status your pipeline reported to GitHub instead of inferring failure from pull-request titles. The teams that see the largest difference are the ones batching several merges into one release, deploying on a schedule, or deploying without a pull request at all.
The setting affects Deployment Frequency and Change Failure Rate only. Lead Time for Changes and Time to Restore stay merge-based.
How Leanmote calculates it
With the default merged-PR source:
deployment_frequency = merged_pull_requests / days_in_selected_range
With GitHub deployments enabled:
deployment_frequency = production_deployments / days_in_selected_range
The denominator is the length of the selected date range in days, so trend lines stay comparable across ranges.
Deployments are bucketed by day (UTC) using the deployment's creation time in GitHub — that's what the chart plots.
Only deployments to an environment GitHub marks as production are counted. If your organization never marks any environment as production, Leanmote counts all deployments rather than showing zero.
Show details lists what was counted: the merged PRs, or — in deployment mode — repository, environment, ref, state, and deploy time for each deployment.
Available views: per team, per repository, and organization-wide.
Switch to GitHub deployments
Go to
Settings → Modules → Performance Delivery.Turn on Measure deployments from GitHub.
The toggle is only available to the organization owner, and only appears when GitHub is connected with at least one active repository — deployment data is GitHub-only today.
What Leanmote reads as a deployment:
Deployments created through GitHub's Deployments API — the usual case for GitHub Actions, Argo CD, Heroku, and similar tooling.
If your pipeline deploys without creating GitHub deployment objects, Leanmote can instead read a named production check run on your release tags. Ask your Leanmote contact to configure the check name for your organization.
Turning the toggle on starts an automatic backfill of up to a year of deployment history (it only fetches the history you're missing). While it runs, the Software Delivery Performance tab shows a "Bringing in your deployment history" notice that clears as soon as data lands — and never stays up longer than 24 hours. Turning the toggle back off returns the metric to counting merged pull requests immediately; captured deployment history is kept.
How to interpret it
Trending up — usually healthy. Often paired with shorter Lead Time.
Trending down while backlog stays high — a red flag for a delivery bottleneck.
Flat with rising failure rate — you've hit a quality ceiling. Investigate test coverage or release process.
A step change right after switching sources — expected, not a bug. Merges and deployments count different events, so don't compare a before-and-after across the switch.
What to do about it
Smaller batch sizes (fewer commits per PR, fewer features per release) typically lift this metric quickly.
Reduce manual approval steps. Each gate is a multiplicative cost.
Improve test reliability so deploys aren't blocked by flaky checks.
Related metrics
Lead Time for Changes
Change Failure Rate
Mean Time to Recovery
DORA metrics overview