DORA metrics

The “DORA metrics” report measures the delivery of a group or a project over the selected period: how often successful deployments to production happen, how long a merged change waits for its deployment, how long incidents stay open and how many incidents come per deployment. The report of a group covers the projects of the group and its subgroups.

Report availability

The report of a project is available to members with the “Reporter” role and above, including those who hold that role in a parent group. Members with the “Guest” role do not see the “DORA metrics” item in the project menu, and the direct address answers with 404. The visibility level of the project does not extend this access: in a public or an internal project, a user who is not a member does not see the report. Turning the “Analytics” feature of the project off closes the report for everyone: the menu item disappears, and the direct address answers with 404.

The report of a group is available to members with the “Reporter” role and above, including those who hold that role in a parent group, and to users of the “Auditor” type. Members with the “Guest” role do not see the item in the group menu, and the direct address answers with 404. For the report of a project, a user of the “Auditor” type needs the “Reporter” role and above in the project or in its parent group.

Viewing the report

To view the report of a group:

1. In the top bar, select “Search or go to…” and pick the group.
2. In the group menu, go to “Analyze” → “DORA metrics”.

To view the report of a project:

1. In the top bar, select “Search or go to…” and pick the project.
2. In the project menu, go to “Analyze” → “DORA metrics”.

The report is also available at a direct address:

The page holds the period list, a row of cards with the value of each metric over the period and a chart per metric with the values by day.

Metrics

The report counts the deployments to the environments of the production deployment tier. A deployment is linked to the merge requests whose commits it brought to the environment since the previous successful deployment of the same environment; the first deployment of an environment is linked to every merge request merged into the deployed branch. A merge request whose merge is recorded after the deployment finished is left out of the lead time.

Incidents are issues of the “Incident” type. An incident belongs to the project as a whole and is counted as an incident of the production tier, so “Time to restore service” and “Change failure rate” have values only in a project with an environment of that tier. An incident marked as a duplicate of another issue is left out of both metrics; an incident that is reopened stops counting as closed.

The values are kept per environment and per day; a day starts and ends by the time zone of the server. A day is counted again from scratch when an event of that day occurs: 5 minutes after a deployment succeeds, once the merge requests it brought are linked to it, and at once when an incident is created, closed, reopened, marked as a duplicate or changes its type to or from “Incident”. Over the period, the deployments and the incidents of its days are summed, and the lead time and the time to restore are the medians of the daily medians. A period without a successful deployment has no “Change failure rate”.

The values are written at the moment of the event. Deployments and incidents that happened before the update that brought the report get their values once an administrator loads the history, as described in Loading history; the same applies to the days counted before the branch list of Branches counted in lead time was changed.

Metric cards

The row above the charts holds a card per metric with its name, its subtitle and its value over the whole period:

• “Deployment frequency” — deployments per day, with the /d suffix;
• “Lead time for changes” and “Time to restore service” — days, with the d suffix;
• “Change failure rate” — a percentage.

A metric without a value in the period shows a dash. When the values cannot be loaded, the card shows “Failed to load DORA metrics.”

Charts

Under the cards, a chart per metric carries the name and the subtitle of its card: a line with one point per day of the period, the vertical axis in the unit of the card and the horizontal axis “Date”. A dashed line across the chart carries the value of the card over the whole period; it is named “Median” on “Lead time for changes” and “Time to restore service” and “Average” on “Deployment frequency” and “Change failure rate”. Pointing at a point shows the date and the value. A day on which the metric has no value carries no point.

A chart with no value on any day of the period shows “No data available” and “Create production deployments and incidents to populate this chart.” When the values cannot be loaded, the chart shows “Failed to load DORA metrics.”

Period

The list in the top right corner of the page sets the period: “Last 7 days”, “Last 30 days”, “Last 90 days”, “Last 180 days” or “Custom range”, which opens the “From” and “To” date pickers. The report opens on “Last 180 days”. A preset period ends with the current day. A custom period is applied once both dates are picked; it ends with the current day or earlier and is limited to 180 days. The icon next to the pickers reads “Dates and times are displayed in the UTC timezone. Date range is limited to 180 days.”

When no metric has a value on any day of the period, the page shows “No DORA metrics available” and “Create production deployments and incidents to populate this dashboard.” in place of the cards and the charts.

Branches counted in lead time

By default, the lead time of a deployment counts every merge request linked to it. In a project that promotes changes through several branches — a merge request into staging, then a merge request from staging into main, and a deployment of main — both merge requests are linked to the deployment, and the same change is counted twice. The DORA configuration of the project names the target branches whose merge requests are counted: with main alone, the merges into staging stay out of the lead time.

The list applies to the environments of the production tier; an environment of another tier keeps every linked merge request. The branch or the tag the deployment was made from is not compared with the list, so a project that deploys tags keeps its lead time. The list cannot be empty and cannot contain empty or repeated names; a project holds one configuration.

The configuration is set from the Rails console. Open the console for the installation type:

sudo gitlab-rails console

docker exec -it code gitlab-rails console

d8 k -n code exec -it deploy/code-toolbox -- gitlab-rails console -e production

d8 k -n d8-code exec -it -c toolbox deploy/toolbox -- gitlab-rails console -e production

Then create the configuration, naming the project by its full path and the branches by name:

project = Project.find_by_full_path('<GROUP>/<PROJECT>')
Dora::Configuration.create!(project: project, branches_for_lead_time_for_changes: %w[main])

To change the list of an existing configuration:

Dora::Configuration.find_by!(project: project).update!(branches_for_lead_time_for_changes: %w[main release])

To return to counting every linked merge request, delete the configuration with Dora::Configuration.find_by!(project: project).destroy!.

The days counted before the configuration was created or changed keep their lead time. To recount them, load the history of the affected period as described in Loading history.

REST API

The values of the report are available through the REST API, one metric per request:

GET /api/v4/projects/:id/dora/metrics
GET /api/v4/groups/:id/dora/metrics

:id is the ID or the URL-encoded full path of the project or the group. The request is authenticated with an access token with the api or read_api scope; the user of the token needs the same access as for the page.

Parameters:

The response is an array of objects with date and value. With daily and monthly, the array holds an object per day or per month of the period, date being the day or the first day of the month and value being null for a day or a month without values; with all, one object with date set to null. Deployment frequency is given in deployments per day, lead time and time to restore in seconds, change failure rate as a fraction from 0 to 1. For a month cut by the period, the deployment frequency divides by the days of the month inside the period.

Response codes:

• 200 — the values;
• 400 — start_date later than end_date, a period longer than 180 days, or a value outside the lists above;
• 401 — no token;
• 403 — the user of the token has no access to the report;
• 404 — the project or the group is not found.

Example:

curl --header "PRIVATE-TOKEN: <TOKEN>" \
  "https://<HOST>/api/v4/projects/<GROUP>%2F<PROJECT>/dora/metrics?metric=deployment_frequency&start_date=2026-03-09&end_date=2026-03-11"

Response for a project with 2 successful deployments to a production environment on 2026-03-10:

[
  { "date": "2026-03-09", "value": null },
  { "date": "2026-03-10", "value": 2.0 },
  { "date": "2026-03-11", "value": null }
]

Loading history

The values are written at the moment of a deployment or an incident. To count the deployments and incidents that happened before the update that brought the report, or to recount the days after a change of the branch list, an administrator runs the gitlab:dora:backfill task with the full path of the project and the first and the last day of the period in the YYYY-MM-DD form:

sudo gitlab-rake 'gitlab:dora:backfill[<GROUP>/<PROJECT>,<START_DATE>,<END_DATE>]'

docker exec code gitlab-rake 'gitlab:dora:backfill[<GROUP>/<PROJECT>,<START_DATE>,<END_DATE>]'

d8 k -n code exec deploy/code-toolbox -- gitlab-rake 'gitlab:dora:backfill[<GROUP>/<PROJECT>,<START_DATE>,<END_DATE>]'

d8 k -n d8-code exec -it -c toolbox deploy/toolbox -- gitlab-rake 'gitlab:dora:backfill[<GROUP>/<PROJECT>,<START_DATE>,<END_DATE>]'

The task takes one project; for the report of a group, run it for each project of the group. It queues a recount of every day of the period on which a successful deployment finished, in the environment of that deployment, and of every day on which an incident was created or closed. In a project without an environment of the production tier, the incident days are not queued. The task prints Enqueued N DORA day recounts. and returns; the recounts run in the background through Sidekiq, and the report fills in as they complete. A day is recounted from scratch, so a repeated run over the same period gives the same values.

The task stops with an error when an argument is missing (project, start_date and end_date are required), when the project is not found (Project not found: <PATH>), when a date is in another form (invalid date) or when the first day is later than the last (start_date must not be after end_date).