Deployment frequency calculator

Define the release event you are counting

Choose the application or service, the production environment or end-user release boundary, and the observation window before counting events. Use the same definition throughout the window. For this calculator, a release event means that the defined change reached that boundary. A merged pull request, a completed build, and a passing test run are different events, even when they precede a deployment. Several such activities may lead to one release, or none. Count the release itself once rather than adding its pipeline operations together.

Record how your definition handles a rollout across multiple regions, a release containing several services, or a staged distribution to end users. This calculator cannot resolve those choices from a single number. For example, your event log might treat one coordinated release as one event and use child records for its regional steps. Another measurement might focus on one service only. Neither number is useful for comparison unless its boundary stays visible. DORA recommends application or service context; the arithmetic here cannot supply that context for you.

Sources: DORA: Software delivery performance metrics

Keep bad releases distinct from failed attempts

Include a release that reached production and then required immediate intervention. Removing it from the release count would hide an event that actually occurred and confuse throughput with its outcome. An attempt that stopped before reaching the defined production boundary is different and is excluded. Preserve both records in your operational evidence so an investigator can understand what happened; only the qualifying production-release event enters this frequency calculation. The calculator does not decide whether an event was healthy based on its presence in the count.

Write a policy for rollbacks, hotfixes, and other rework before reviewing the totals. The example below counts a rollback that releases a restored version to production as its own event, and counts a production hotfix separately. It still includes the earlier release that caused the incident. This is a stated counting policy for the example, not an assertion that every operational recovery action is another deployment. A restart, alert acknowledgement, or retry of a pre-production step should not become a release merely because it appears in the same incident timeline.

Sources: DORA: Software delivery performance metrics

A synthetic 28-day measurement log

The following log is a fictional teaching example, not customer data or evidence of Agentic Pipeline performance. It covers one application’s production releases over 28 complete calendar days. Each summarized row represents a set of distinct event identifiers. Routine releases are listed separately from the incident-related events so they are not counted twice. This example counts a restored-version rollback as a production release, while excluding a CI failure and an attempt that stopped before production.

The counted events sum to 14. Divide 14 by 28 to obtain 0.5 releases per calendar day. Multiply by seven to express the same rate as 3.5 releases per seven days. Divide the 28-day window by 14 events to obtain an implied two-day interval. The fractional weekly result does not mean half a release happened: it is a normalized rate over a longer window. Changing the reporting unit changes the displayed scale, not the underlying set of events.

Releases per day = release count ÷ calendar days
Releases per seven days = 7 × release count ÷ calendar days
Implied interval in days = calendar days ÷ release count
With zero releases: both rates are zero; implied interval is Not applicable.

Use a consistent calendar window

Include weekends, holidays, and days without releases in the calendar-day denominator. This calculator accepts one to 3,660 complete days and a whole-number release count up to one million. It does not accept fractional windows or convert working days into calendar days. Record the start, end, timezone, and boundary convention alongside the inputs. For adjacent reporting periods, an inclusive start and exclusive end is one way to assign an event at a boundary exactly once; apply your chosen convention consistently.

A zero count is a valid observation only when the event collection is complete enough to support it. Missing records, unavailable telemetry, or an incorrectly scoped query should remain an unknown result in your measurement process rather than being entered as zero. If no qualifying releases occurred in a fully observed window, both rates are zero and the implied interval is undefined. Not applicable communicates that distinction without presenting an infinite delay as an observed duration.

An implied interval is not a measured median

The interval output uses only two inputs: a total count and a window length. It has no event timestamps from which to measure actual gaps. Fourteen releases spread across a month and fourteen releases clustered into one afternoon can produce the same rate and implied interval. Their delivery patterns are plainly different. The two-day value in the default example therefore must not be described as the median time between releases, a typical customer wait, or a release schedule.

To study actual spacing, retain the ordered timestamps and define how you handle the window’s beginning and end. Consecutive gaps require pairs of events, and the observation period may start before the first recorded release or end after the last. This calculator deliberately does not estimate those gaps or their distribution. Use its rate for a clearly bounded count comparison, and use timestamp-based analysis when the question concerns bunching, long pauses, or the time users waited for a change.

Read frequency alongside the other DORA metrics

DORA’s current guide presents five software delivery performance metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. Frequency belongs to the throughput view. It does not by itself describe release quality or the amount of incident-related work. This calculator reports the entered count as a rate without assigning a performance grade, benchmark category, or target. A larger number is a reason to examine the delivery context, not a complete assessment of a team.

The definitions have changed over time. DORA’s history explains the move from the familiar four-key framing to a five-metric model that includes deployment rework rate, and the refinement of recovery time around failed deployments. When comparing a current report with an older dashboard, check the definitions as well as the numbers. Keep the source and measurement version in the report so changes in terminology or collection rules are not mistaken for improvements in delivery.

Sources: DORA: Software delivery performance metrics · DORA: A history of software delivery metrics

Keep the evidence with the result

Save the scope, window, counting policy, and event identifiers with the result. The share link carries only the numeric inputs, and the local JSON export includes the model’s assumptions; neither replaces your underlying release log. When the rate changes, first check whether the service boundary, event collection, or policy changed. Then examine the actual delivery work and the outcomes of the releases. This makes a discussion about a measured change more useful than pursuing a higher number without knowing what it represents.

Agentic Pipeline’s public feature guide describes evidence for following delivery through a verified live version and controls that coding agents can inspect. Those capabilities can be evaluated as part of collecting and investigating release evidence; this calculator does not query a deployment system or verify the events you enter. Access is currently closed beta. Use the tool to make an explicit count-based comparison, and keep incident outcomes and the other delivery metrics beside that comparison when choosing an improvement.

Sources: Agentic Pipeline: Public feature guide