The five measures

Changeline counts the five DORA measures from what Jira holds, in the two groups DORA gives them: throughput (deployment frequency, change lead time, failed deployment recovery time) and instability (change fail rate, deployment rework rate). Each is one rule, set once for the site in Settings, and each figure shows its count under it: how many releases, work items or failures it came from. No figure is about one person: Changeline reads no assignee or reporter and shows no person’s name in a figure.

There are no bands. DORA’s 2025 report dropped Elite, High, Medium and Low, and says a team improves against its own past, not against other teams. Each figure carries only a lozenge for whether it is better or worse than the days just before. See Against your own past.

Deployment frequency

Each deployment in the period counts once. By default a deployment is a released version of a space in the scope: a version marked Released, with its release date in the period. In Done mode, each work item of the scope whose status category became Done in the period counts instead. See What counts as a deployment.

The figure is deployments a day when there is one or more a day, else a week, else a month: 3.2 a week. Under it is the count, such as 14 releases in 90 days.

Change lead time

For each work item deployed in the period, lead time runs from its start to its deployment.

• The start is the first time the work item moved out of a To Do status, read from its history. A work item never seen leaving To Do starts at its creation. A Jira admin can start every work item at its creation instead.
• The deployment is the work item’s first released version on or after its start, at the end of that day. In Done mode it is the work item’s resolution date, else the day its status category changed to Done.

The figure is the median, such as 4.5 days, with the count under it: of 120 work items. A work item whose end is before its start is left out and counted in a grey line.

DORA starts the clock at the commit. Jira gives an app no commit times, so Changeline starts it when work starts. A Jira Automation rule, “Branch created → move to In Progress” (GitHub, GitLab or Bitbucket for Jira), makes the two the same.

Failed deployment recovery time

For each failure recovered in the period, recovery time runs from the failure’s creation to the release that ships its fix, named in its Fix versions, else to its Done. The figure is the median, such as 6h 20m, with the count under it. A failure not yet recovered is listed apart, named in an amber box, and joins the figure when it is. See Failures and recovery time.

DORA used to call this time to restore, and many teams still say MTTR.

Change fail rate

A deployment failed when a failure points at it: a work item of a failure type whose Affects versions names the release, or that links to a work item of that release, with any link type. Bug is a failure type by default, and so is every work type whose name contains Incident. In Done mode a failure is a link to a deployed work item, from a work item created after it.

The figure is the failed deployments out of all deployments: 12%, with 3 of 25 releases under it. DORA used to call this change failure rate. See Failures and recovery time.

Deployment rework rate

A deployment is rework when it ships a fix for a failure of an earlier deployment: a release named in the Fix versions of a failure that points at an earlier release. The figure is the rework deployments out of all deployments: 8%, with 2 of 25 releases under it. DORA added it in 2024, beside change fail rate, as a second measure of instability. The Releases tab has a Rework column.

Against your own past

Each figure is set against the same number of days just before the period: Last 90 days against the 90 before them. Beside it, on one line, a lozenge says how it moved, green when it is better and red when it is worse:

• Deployment frequency in deployments, such as 1.3 more a month or 2 fewer a week, in the unit that reads best for the larger of the two rates. It is drawn when the days before held a deployment.
• Change lead time and failed deployment recovery time as a share of the earlier median, such as 18% faster or 35% slower.
• Change fail rate and deployment rework rate in points, such as 4 points lower or 8.3 points higher.
• Same as the 90 days before, in grey, when nothing moved.

The count line shows the figure before, such as 3 of 8 releases · was 50%. Hover a lozenge to see it in full. When there is nothing to count on one side, the figure has no lozenge. The Space chip counts the days before for that space too, and the dashboard gadget shows the same lozenges. Changeline reads both periods in one pass, so a read of more than 5,000 work items, or one that takes too long, drops the days before: a grey line says The days before were too much to read with these, so nothing is compared, and the figures stand.

Where the lead time goes

Under the five figures, Where the lead time goes splits the lead time of the period into three stages, for the work items deployed in it. Each stage is the median of those work items, drawn as one bar in three parts with the three medians as its legend, and the largest one named: Most of it waits for a release, Most of it waits to start or Most of it is work in progress.

• Waiting to start: from a work item’s creation to its first move out of To Do.
• In progress: from there to its first move into Done.
• Waiting for release: from Done to the release that shipped it. In Done mode a work item is deployed when it is Done, so there are two stages.

A stage is never negative: a work item released before it was Done spent no time waiting for the release, and one Done before it started none in progress. Each median counts the work items that have that stage, so the three do not always add up to the lead time. When lead time starts at the first move out of To Do, waiting to start is before that clock. When it starts at creation, the three split the lead time. The Releases tab gives the three stages for each release, and the downloads carry them. Each work item’s own three are in the work item panel.

The period

The Period chip sets the last 30, 90 (the default), 180 or 365 days. The Trend tab shows a row a week for 30 and 90 days and a row a month for 180 and 365, with a chart above it.

The Trend chart

The Chart chip above the chart picks its measure: Deployments (the default), Change lead time in median days, Failed deployment recovery time in median hours, Change fail rate or Deployment rework rate in percent of deployments, a column for each week or month. The subtitle names the unit, and Copy link keeps the pick.

The Spaces tab

Under Apps › Changeline, when the work comes from more than one space, a Spaces tab comes first and opens first: a row for each space with its five figures, so teams sit side by side. It counts from the work already read, whatever the Space chip says, and costs no further read. A failure counts in its own space, so a service space that keeps failures shows recovery time alone, and a space with no deployment shows only what it has. A row is a space, never a person. The Excel download has the Spaces sheet first, and the CSV is the tab you are on.

DORA here is the research programme at Google behind these five measures, not the EU’s Digital Operational Resilience Act. DORA is a trademark of Google LLC, and Changeline is not made or endorsed by Google.