> ## Documentation Index
> Fetch the complete documentation index at: https://docs.weaveos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# CI deploy frequency

> Count of production deployments per time period

## 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](https://dora.dev/guides/) 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:**

```
Deploy frequency = Number of completed production deployment runs in each day, week, or month
```

### 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](/metrics/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:

| Performance Level | Deploy Frequency |
| - | - |
| **Elite** | Multiple times per day |
| **High** | Once per day to once per week |
| **Medium** | Once per week to once per month |
| **Low** | Less than once per month |

## 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

<Note>
  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.
</Note>

## Technical details

<AccordionGroup>
  <Accordion icon="plug" title="How are deployments detected?">
    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
  </Accordion>

  <Accordion icon="filter" title="How are production deployments identified?">
    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.
  </Accordion>

  <Accordion icon="calendar" title="What time period is used?">
    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.
  </Accordion>

  <Accordion icon="chart-line" title="What data sources are used?">
    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
  </Accordion>
</AccordionGroup>

## Public API

Available from [`GET /metrics`](/api-reference/metrics/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.

## Related metrics

* **[CI deploy success rate](/metrics/ci-deploy-success-rate):** Percentage of deployments that succeed
* **[CI deploy MTTR](/metrics/ci-deploy-mttr):** Time to recover from failed deployments
* **[PR deploy lead time](/metrics/pr-deploy-lead-time):** Time from PR merge to production deployment


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.