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
Viewing the report
To view the dashboard of a group:
- In the top bar, select “Search or go to…” and pick the group.
- In the group menu, go to “Analyze” → “Value streams dashboard”.
To view the dashboard of a project:
- In the top bar, select “Search or go to…” and pick the project.
- In the project menu, go to “Analyze” → “Value streams dashboard”.
The dashboard is also available at a direct address:
| Dashboard | Address |
|---|---|
| Group | https://<HOST>/groups/<GROUP>/-/analytics/dashboards/value_streams_dashboard |
| Project | https://<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 “<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 “
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
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:
- In the top bar, select “Search or go to…” and pick the top-level group.
- In the group menu, go to “Settings” → “Analytics”.
- 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.”
- 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
- 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:
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:
| Row | Content |
|---|---|
| “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:
- “Lead time” and “Cycle time” — Value stream analytics;
- “Issues created” and “Issues closed” — Issue analytics;
- “Deploys”, “Median time to merge” and “Merge request throughput” — on the group page Productivity analytics, on the project page Merge request analytics.
DORA metrics table
The “DORA metrics for 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 <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 more | fewer than one deployment in 30 days |
| “Lead time for changes” | 7 days or less | more than 30 days |
| “Time to restore service” | one day or less | more than 7 days |
| “Change failure rate” | 15% or less | more 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 <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.