Available since 1.16.2 (EE)

The “Value streams dashboard” shows the overview counters of a group or a project, its lifecycle and DORA metrics for the last six months by month and, for a group, how its projects score on the DORA metrics. The dashboard of a group covers the group, its subgroups and all their projects. A personal project, one in the namespace of a user, has no dashboard.

The dashboard takes no period and no filters: the tables cover the five past calendar months and the current month, and the counters show the latest snapshot.

Report availability

The dashboard of a group is available to members of the group with the “Reporter” role and above, and to users of the “Auditor” type. Members with the “Guest” or “Planner” role do not see the “Value streams dashboard” item in the group menu, and the direct address answers with 404. The visibility level of the group does not extend this access: with the “Public” or “Internal” level, a user who is not a member of the group does not see the dashboard.

The dashboard of a project is available to members of the project with the “Guest” role and above, including those who hold that role in a parent group, and to users of the “Auditor” type. In a project with the “Public” visibility level, the dashboard is open to any visitor, including one who has not signed in. With the “Internal” visibility level, the dashboard is open to any signed-in user except users of the “External” type. This holds while the “Analytics” feature of the project is set to “Everyone With Access”; with “Only Project Members”, users who are not members of the project, except users of the “Auditor” type, get 404. In a project where the “Analytics” feature is disabled, or issues and merge requests are both disabled, the menu item is absent and the direct address answers with 404. A personal project has neither the menu item nor the page.

The DORA panels need a permission of their own: the “DORA metrics for ” table and, on the group page, the “DORA performers score for ” chart and the “Projects by DORA metric in ” table. Members with the “Reporter” role and above hold it in the group and in the project; users of the “Auditor” type hold it in the group only. Without it the panels stay on the page and show “You have insufficient permissions to view this panel.” in place of their content. A member with the “Guest” role, a visitor of a public project, a signed-in user who is not a member of an internal project and a user of the “Auditor” type on a project page see the DORA panels this way. On the group page, a user of the “Auditor” type who is not a member of the group sees the data of the “DORA metrics for ” table and the “DORA performers score for ” chart, and the “Projects by DORA metric in ” table reads “No results match your query or filter.”

Viewing the report

To view the dashboard 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” → “Value streams dashboard”.

To view the dashboard 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” → “Value streams dashboard”.

The dashboard is also available at a direct address:

DashboardAddress
Grouphttps://<HOST>/groups/<GROUP>/-/analytics/dashboards/value_streams_dashboard
Projecthttps://<HOST>/<GROUP>/<PROJECT>/-/analytics/dashboards/value_streams_dashboard

Panels

The group page holds, from top to bottom:

  • the “ overview” card;
  • the counters “Groups”, “Projects”, “Users”, “Issues”, “Merge requests” and “Pipelines”;
  • the “Lifecycle metrics for ” table;
  • the “DORA metrics for ” table;
  • the “DORA performers score for ” chart;
  • the “Projects by DORA metric in ” table.

The project page holds the “ overview” card, the counters “Issues”, “Merge requests” and “Pipelines”, and the “Lifecycle metrics for ” and “DORA metrics for ” tables. <NAMESPACE> in a panel title is the name of the group or the project.

A panel whose data failed to load shows “Something went wrong.”, and an error icon appears next to its title; pointing at the icon shows the details and “Retry”.

Overview card and counters

The “ overview” card shows the avatar, the full name with a link to the group or the project, the type (“Group” or “Project”) and the visibility level (“Public”, “Internal” or “Private”).

The counters are snapshots taken in the background once a month, in the last three days of the month, for the hierarchies whose top-level group turned the counting on, as described in Enabling the overview counting. A counter reads the newest snapshot taken within the last year and shows “Last counted ” under the value, with the date and time of the snapshot. The snapshot covers every group and project of the hierarchy, so the dashboard of a subgroup reads the part of the snapshot that belongs to the subgroup.

On the group page the counters are:

  • “Groups” — the subgroups of the group at all levels;
  • “Projects” — the projects of the group and of its subgroups;
  • “Users” — the direct members of the group itself; members of subgroups, pending invitations and access requests are not counted;
  • “Issues”, “Merge requests” and “Pipelines” — across the projects of the group and of its subgroups; “Issues” counts issues of every type, incidents included, and a merge request is counted in its target project.

On the project page, “Issues”, “Merge requests” and “Pipelines” count the project itself, “Issues” with every issue type.

While the top-level group has not turned the counting on, the counters show 0, and a warning at the top of the page reads “The overview counts of groups, projects, users, issues, merge requests and pipelines are not collected for this hierarchy, so those panels show zero.” A user who can open the settings of the top-level group sees it followed by “Turn on the background counting in the analytics settings of the top-level group.”, where “analytics settings” links to the page; anyone else sees “An owner of the top-level group can turn on the background counting in its analytics settings.” Each counter panel also shows a warning icon next to its title; pointing at it shows “This count is taken in the background once a month, and the top-level group has not turned that on.” The warning at the top of the page can be closed; it returns when the page is reloaded.

Once the counting is turned on, the warning at the top is gone; until the first snapshot, the counters show 0, and pointing at the warning icon of each counter panel shows “No snapshot of this count has been taken yet. The background counting runs once a month.” Once the counting is turned off, the counters show 0 again with the first warning, whichever snapshots were taken.

Enabling the overview counting

The counting is turned on in the settings of a top-level group by a member with the “Owner” role or by an administrator. A subgroup has no such page: the “Analytics” item is absent from its “Settings” menu, and the direct address answers with 404.

To turn the counting on:

  1. In the top bar, select “Search or go to…” and pick the top-level group.
  2. In the group menu, go to “Settings” → “Analytics”.
  3. In the “Value streams dashboard” section, select “Enable overview background aggregation”. The section reads “The overview counts of the dashboard are taken in the background once a month for the whole group hierarchy.”, and the checkbox “Without it the overview panels show no counts.”
  4. Select “Save changes”. The page reports “Analytics settings were successfully updated.”

The page is also available at https://<HOST>/groups/<GROUP>/-/settings/analytics.

The snapshot of a hierarchy is taken in the last three days of the month, once per month; a hierarchy that turns the counting on earlier in the month gets its first snapshot in those days. The job runs hourly, and a hierarchy too large for one run is continued on the next. While the instance is in maintenance mode, the job does not count.

To turn the counting off, clear “Enable overview background aggregation” and select “Save changes”.

Lifecycle metrics table

The “Lifecycle metrics for ” table has the “Metric” column, six month columns headed by the month and the year, the “Change (%)” column and the “Trend” column:

  • The month columns are the five past calendar months, oldest first, and the current month to today; the months are cut in the time zone of the browser. On the first day of a month, by that time zone, the last column is the month just ended, whole, and the column of the new month appears on the second day.
  • “Change (%)” is the change of the column before the last against the first column, five months earlier; the last column is not compared. The badge is green when the change improves the row and red when it worsens the row: for a count, a rise improves it; for a duration, a fall. It reads “0%” when both months are zero, and “n/a” when one of the two months has no value or only the earlier month is zero; in both cases the badge is grey.
  • “Trend” is a line over the first five columns, without the last one; a row with a value in only one of these months shows that month as a point.

Every cell is computed when the page opens. A cell without a value reads “-”. Durations are in days. The icon next to a row name opens the description of the row. A row whose data failed to load is named in the warning “Some metric comparisons failed to load: ”, shown with “Retry” when pointing at the warning icon next to the panel title.

A month counts what finished in it: an issue closed or a merge request merged in the month, whenever it was created. “Issues created” counts the issues created in the month. The rows:

RowContent
“Lead time”Median time from the creation of an issue to its closing, over the issues closed in the month
“Cycle time”Median time from the first commit that mentions an issue to the closing of that issue, over the issues closed in the month
“Issues created”Issues created in the month
“Issues closed”Issues closed in the month; a month with more than 1000 such issues shows 1001
“Deploys”Successful deployments to production environments finished in the month
“Merge request throughput”Merge requests merged in the month, in projects that are not archived and whose merge requests you can see
“Median time to merge”Median time from the creation of a merge request to its merge, over the merge requests merged in the month

Each row name links to the report that details it:

DORA metrics table

The “DORA metrics for ” table has the same columns as the lifecycle table. Its rows are computed over the production environments, the environments of the production deployment tier, of the project or, on the group page, of all projects of the group and its subgroups, from the daily values described in Recording of DORA metrics:

  • “Deployment frequency” — successful deployments per day: the deployments of the month divided by its calendar days, for the current month by the days to today;
  • “Lead time for changes” — the median time, in days, from the merge of a merge request to the end of the deployment that delivered it, taken over the daily medians of the month, and in a project with a branch list only for the merge requests into those branches, as described in Branches counted in lead time;
  • “Time to restore service” — the median time, in days, from the creation of an incident to its closing, taken over the daily medians of the month;
  • “Change failure rate” — incidents created in the month per deployment to production environments of the month, in percent, and “-” for a month without deployments.

The badge of “Change (%)” is green for a rise of “Deployment frequency” and for a fall of the other three rows. Each row name links to the DORA metrics report.

“Deploys” of the lifecycle table counts the deployments themselves, while “Deployment frequency” reads the recorded days. A deployment made before the update to the version with the dashboard counts in “Deploys” at once and in “Deployment frequency” once the history is loaded, so the two rows can differ for those months. The rows can also differ at the edges of a month when the time zone of the browser differs from the time zone of the instance: “Deploys” cuts the months in the browser, while the recorded days follow the instance.

DORA performers score

The “DORA performers score for ” chart is on the group page only. It scores each project of the group and its subgroups that you can see, for the last full calendar month, on each DORA metric, and shows one column per metric: the “High”, “Medium” and “Low” segments count the projects with that score, the “No data” segment counts the scored projects without a value for the metric. The axes read “DORA metric” and “Projects”. The caption reads “Scored projects for the last full month; of them have no DORA data.”, where <N> is all the projects of the group and its subgroups that you can see, the projects without data included, and <M> is the projects with no recorded DORA day on a production environment in that month; these projects are in no column. Pointing at a column shows the thresholds of its metric.

A project is scored for a month once an event on one of its production environments is recorded on a day of that month. The score of each metric:

Metric“High”“Low”
“Deployment frequency”one deployment a day or morefewer than one deployment in 30 days
“Lead time for changes”7 days or lessmore than 30 days
“Time to restore service”one day or lessmore than 7 days
“Change failure rate”15% or lessmore than 45%

Between the two thresholds the score is “Medium”. When no project of the group is scored for the month, every column counts all projects under “No data”, and the chart adds “No project was scored for: .”

Projects by DORA metric

The “Projects by DORA metric in ” table is on the group page only. It lists the projects of the group and its subgroups that you can see and that have a value of a DORA metric for production environments in the last two full months: the “Project” column with the avatar and the name linking to the project, then a column per DORA metric with the value of the last full month and a badge with its change against the month before. The caption reads “Showing of projects; have no DORA data for the last two months.” When no project has such a value, the table reads “No results match your query or filter.” and has no caption. A project with the “Analytics” feature disabled is not listed and is counted under <K>.

The table opens sorted by “Project”; select a column header to sort by it. Projects without a value in the column are listed last, whichever direction is selected.

Recording of DORA metrics

The four metrics, their daily charts and their REST API are described on the DORA metrics page.

DORA values are recorded per environment and per day, at the moment an event happens:

  • a successful deployment is counted on the day it finished; the lead time for changes is measured from the merge of each merge request linked to the deployment to the end of the deployment and is recorded 5 minutes after the deployment and once more if linking its merge requests finishes later;
  • an incident created, closed or reopened is recorded on the oldest production environment of the project: the incident on the day it was created, its time to restore on the day it was closed; an incident marked as a duplicate is left out;
  • an issue changed to or from the “Incident” type, or marked as a duplicate or unmarked, is recounted on the day of its creation and, when it is closed, on the day of its closing;
  • deleting an incident recounts the day of its creation and, when it is closed, the day of its closing.

The day of an event, and so the month it falls into, is taken in the time zone configured for the instance, UTC by default. The dashboard reads production environments only, so a deployment to an environment of another tier does not count.

Recording starts with the first event after the update to the version with the dashboard. The deployments and incidents of the time before it, and the incidents created before the project had a production environment, get their values once an administrator loads the history, as described in Loading history. Deleting an environment removes its recorded days; deleting the oldest production environment of a project removes the incident history of the project with it.