Skip to main content

​
How it works

CI deploy frequency measures how often your team deploys code to production. This is one of the four key DORA (DevOps Research and Assessment) metrics used to measure software delivery performance. Higher deployment frequency indicates:
  • Faster delivery of features and fixes to users
  • Smaller, lower-risk changes
  • More automated and reliable deployment processes
  • Better team confidence in the deployment pipeline

​
Calculation

The metric counts completed production pipeline runs in the selected time period, including failed and cancelled runs. Each run attempt is counted once, regardless of how many commits or PRs it includes, so re-running a deployment adds another one. If Merges as deployments is turned on for your organization, each PR merged into a configured branch also counts as one deployment, unless it’s already linked to a production CI run. Formula:

​
What counts as a deployment

A deployment is counted when:
  • A CI/CD workflow run completes, whether it succeeds, fails, or is cancelled (use CI deploy success rate to see how many succeed)
  • The workflow is tagged as a production deployment
  • The deployment target is a production environment

​
Supported CI/CD platforms

  • GitHub Actions: Workflows classified as production deployments
  • Azure DevOps: Build pipelines and classic Release Management pipeline deployments
  • GitLab CI/CD: Pipelines classified as production by name, tag pipelines matching a per-project production tag regex, or, if you turn it on, every branch pipeline on each project’s default branch
  • CircleCI: Workflows classified as production deployments
  • Jenkins: Jobs configured as production deployments
  • Argo CD: Application syncs classified as production deployments

​
Industry benchmarks

Based on DORA research:

​
Why it matters

Deployment frequency is a leading indicator of:
  • Development velocity: How quickly you can deliver value
  • Process efficiency: Automated, reliable deployment pipelines
  • Team culture: Confidence in testing and deployment
  • Risk management: Smaller, more frequent changes are lower risk
Teams that deploy more frequently typically have:
  • Better automated testing
  • More robust CI/CD pipelines
  • Stronger DevOps practices
  • Faster incident response

​
Improving deploy frequency

To increase deployment frequency:
  1. Automate deployments: Eliminate manual steps in the deployment process
  2. Reduce batch size: Ship smaller, more focused changes
  3. Improve test coverage: Build confidence in automated testing
  4. Enable feature flags: Deploy code without exposing features
  5. Adopt trunk-based development: Reduce long-lived branches
  6. Monitor deployment health: Track success rates and rollback procedures
Deploy frequency should be balanced with deploy success rate and mean time to recovery (MTTR). Deploying frequently with low success rates or slow recovery times indicates underlying problems.

​
Technical details

Weave detects deployments through CI/CD platform integrations:GitHub Actions:
  • Workflows classified as production from their name, the branches they run on, and the GitHub deployment environments of their commits
  • If you set deployment confirmation job names for a workflow, runs whose confirmation jobs were all skipped aren’t counted
Azure DevOps:
  • Build pipelines configured for production deployment
  • Classic Release Management pipeline deployments (each release environment is classified independently)
GitLab CI/CD:
  • Pipelines of enabled projects, identified by pipeline name (workflow:name) and classified as production or not; review the classification in Organization settings → Repositories → Production deployments
  • Per-run values in pipeline names (commit SHAs, merge request numbers, release versions) are grouped, and tag pipelines are classified separately
  • Or, for projects with a production tag regex, only tag pipelines whose tag matches the regex, plus default-branch pipelines if the default-branch rule is on
  • Optionally, turn on Count pipelines on each project’s default branch as production deploys to count every branch pipeline on each project’s default branch; merge request, tag, and scheduled pipelines aren’t counted by this rule
  • GitLab environments and the GitLab deployments API are not used
CircleCI:
  • Workflows classified as production from their name and the branches they run on
  • CircleCI contexts and job names aren’t used
Jenkins:
  • Builds configured as production deployments
  • Environment build parameters (such as DEPLOY_ENV or ENVIRONMENT) inform the classification
Argo CD:
  • Application syncs classified as production deployments
Each workflow or pipeline is classified as a production deployment or not:
  1. Automatic classification: Weave predicts whether each workflow deploys to production, based mainly on its name and the branches it runs on. Deployment environment names, when the platform reports them, only confirm the prediction.
  2. Your review: You can change the classification for each workflow in Organization settings → Repositories → Production deployments.
  3. GitLab rules: For GitLab, you can also set a per-project production tag regex or count every pipeline on each project’s default branch.
Non-production deployments (staging, development, preview) are excluded from this metric.
The metric counts deployments within your selected time range, grouped by when each run was created:
  • Daily view: Raw count of deployments per day
  • Weekly view: Count of deployments per week
  • Monthly view: Count of deployments per month
Counts aren’t normalized to a daily rate. The chart headline shows the average number of deployments per day, week, or month, matching the view you select.
CI deploy frequency uses data from:
  • GitHub Actions: Workflow run data via GitHub API
  • Azure DevOps: Build and classic Release Management deployment data via Azure DevOps API
  • GitLab CI/CD: Pipeline data via GitLab API
  • CircleCI: Pipeline execution data via CircleCI API
  • Jenkins: Build data via Jenkins API
  • Argo CD: Application sync history via the Argo CD API, or events from Argo CD Notifications webhooks

​
Public API

Available from GET /metrics as ci_deploy_frequency: a count of completed production pipeline runs in each time bucket, plus merged PRs counted as deployments when Merges as deployments is turned on. Requires a CI/CD connection and production-classified workflows. group_by is not supported; teams and accounts filters still apply.
Last modified on October 17, 2026