Deployment frequency

How is deployment frequency measured?

Deployment frequency is a simple count: the number of successful production deploys in a chosen window, divided by that window. Most teams report it per day, per week or per month. Almost every CI/CD platform already has the raw events, so the work is in defining the count, not in collecting data.

Three rules keep the number honest:

1. Production only. A deploy to staging, qa or a sandbox preview environment does not count. The whole point of the metric is to ask how often value reaches users.
2. Successful only. A run that failed before the artifact was live in production is not a deploy. If a deploy succeeded but you immediately rolled back, the deploy still happened. Log it, and let change failure rate and MTTR capture the consequence.
3. One definition, applied every time. Pick what a "deploy" means for your service (a new artifact version published, a container image promoted, a Helm release applied, a feature flag flipped on) and stick with it. Inconsistent definitions are the single biggest reason two teams' dashboards disagree.

The DORA State of DevOps reports group teams into bands so you can see where you sit:

Band	Deployment frequency
Elite	On demand, multiple times per day
High	Between once per day and once per week
Medium	Between once per week and once per month
Low	Less than once per month

Treat the bands as a direction signal, not a leaderboard. A regulated payments service deploying once a week with near-zero failure rate is not "worse" than a marketing site deploying twenty times a day. What matters is the trend for your service and whether it is moving in the direction you intend.

Why does deployment frequency matter?

The headline finding from the Accelerate research is counter-intuitive: teams that deploy more often are also more reliable. Speed and stability move together because the same practices drive both: smaller batches, automated tests, fast rollback, and short-lived branches. A team that deploys ten times a day has, by necessity, paid down the friction that makes any single deploy scary.

Beyond benchmarking, deployment frequency is the cheapest delivery signal you can collect, and it points at concrete bottlenecks:

• Falling frequency usually means batch size is growing: long-lived branches, lots of pre-prod waiting on a coordinator, or a fragile suite that scares people off pushing.
• Frequency stuck at "weekly Tuesday release" is the classic sign of a release-train cadence that nobody dares break, even when smaller increments are ready.
• Frequency that looks healthy but pairs with a rising change failure rate is the most dangerous pattern: the team is moving fast and breaking things. Slow down and shore up tests, observability and rollback before pushing speed further.

One honest caveat: deployment frequency is easy to game. A team under pressure to "ship more" can split commits, replay the same artifact, or quietly reclassify hotfixes as separate deploys. Pin the metric to a system trend, never to an individual's review, and audit the definition every few months.

How do popular CI/CD tools surface deployment frequency?

The raw events live in whatever runs your pipeline. The interesting question is how each tool helps you turn those events into a defensible chart.

• GitHub Actions + GitHub: the deployments API and open-source DORA actions can compute deployment frequency directly from workflow runs and the Deployment objects GitHub already records. Low friction for GitHub-native teams; the data is structured well enough that a single workflow can write straight to a dashboard.
• GitLab CI: built-in Value Stream Analytics ships deployment-frequency charts on Premium/Ultimate with no glue code. If you are already paying for GitLab Premium, that is the cheapest credible dashboard you can get: nothing else to wire up, no third party in the loop. Hard to beat on price-per-chart.
• Jenkins: no built-in DORA view, but the long-running build history is a perfectly good event source. In regulated shops where Jenkins already owns the audit trail, a small Groovy job posting to a metrics endpoint is usually the path of least resistance.
• Argo CD / Argo Rollouts: emits rich deployment events into Kubernetes, which a community Grafana dashboard can turn into per-service deployment-frequency graphs. For Kubernetes-heavy shops that want the number alongside cluster telemetry, this is the natural choice.
• Specialised DORA platforms: Sleuth, LinearB and Jellyfish plug into VCS, CI/CD and the incident tracker to produce org-wide DORA dashboards. If you need a board-ready view across dozens of teams, a dedicated product still wins on polish and drilldowns.
• Buddy is one solid option when the bottleneck is getting to a higher deployment frequency in the first place, not just measuring it. ON_EVERY_PUSH pipeline triggers, branch-scoped refs and a built-in HTTP action let a small team wire a push-to-prod pipeline (plus a structured deploy-event hook for whatever dashboard they already use) in an afternoon. The visualisation still happens elsewhere; Buddy's role is to make every successful production push a clean, timestamped event.

There is no single winning tool here. Pick whichever already owns your pipeline data, lift frequency by shrinking the unit of change rather than by chasing the number, and only add a separate dashboard layer once the count outgrows a shared spreadsheet.

Example

A minimal Buddy pipeline that ships every push to main and forwards a structured deploy event to whatever endpoint your dashboard reads from. Each successful run on main becomes one tick in the deployment-frequency series, with no extra agent and no application instrumentation.

# .buddy/buddy.yml — every push to main = one production deploy event
- pipeline: "deploy-production"
  events:
    - type: "PUSH"
      refs:
        - "refs/heads/main"
  variables:
    - key: "SERVICE"
      value: "checkout-api"
    - key: "METRICS_ENDPOINT"
      value: "https://metrics.example.com/deployments"
  actions:
    - action: "Build & deploy"
      type: "BUILD"
      docker_image_name: "node"
      docker_image_tag: "20"
      commands: |-
        npm ci
        npm run build
        ./scripts/deploy.sh

    - action: "Record production deploy"
      type: "HTTP"
      method: "POST"
      notification_url: "${METRICS_ENDPOINT}"
      trigger_time: "ON_SUCCESS"
      headers:
        - name: "Content-Type"
          value: "application/json"
      content: |
        {
          "service":     "${SERVICE}",
          "commit":      "${BUDDY_EXECUTION_REVISION}",
          "environment": "production",
          "deployed_at": "${BUDDY_EXECUTION_FINISH_DATE}",
          "outcome":     "success"
        }

Counting deployment frequency from there is one SQL query: count(*) by date(deployed_at) against the events table. The metric becomes a by-product of how the pipeline already runs, not a separate project competing for headcount. The moment the number plateaus, the conversation moves to the right place: branch size, test speed and review latency, not the dashboard itself.