Legend

Every number counts back from the time in the footer: deployment frequency from the successful deployments, lead time for changes from the commits they shipped, failed deployment recovery time from the failed deployments and the successful ones after them, change fail rate from the failed deployments and the issues labelled failure, deployment rework rate from the successful deployments that came after a failed deployment or while a failure issue was open.

The window is 30 days (the default; dora_days is not set in forsgren.config.yml).

A project's total row counts all its repositories; a row under it counts what its label names in the project's config. Durations: min is minutes, h hours, d days, each cut down, never rounded up.

Deployment frequency

The DORA band, then the successful deployments of the last 30 days, or of the last 180 days when the 30 days hold none:

A working day is configured as 8 hours (the default; working_hours is not set in forsgren.config.yml).

• On demand (multiple deploys per day): 241 and more in 30 days (more than once an hour over a working day of 8 hours), score 10
• Between once per hour and once per day: 30 to 240 in 30 days, score 8
• Between once per day and once per week: 5 to 29 in 30 days, score 6
• Between once per week and once per month: 1 to 4 in 30 days, score 4
• Between once per month and once every six months: none in 30 days, 1 and more in 180 days, score 2
• Less than once per six months: none in 180 days, score 0

The next column, Weekend deployments, is how many of the successful deployments that count were created on a Saturday or a Sunday, UTC, over the same 30 or 180 days; it is 0 when there are none. The numbers view shows the last 30 days.

Lead time for changes

The DORA band, then the median time from a commit to the successful deployment that shipped it, and in brackets the commits deployed in the last 30 days. A month is 30 days:

• Less than one hour: below 1 hour, score 10
• Less than one day: 1 hour to below 24 hours, score 8
• One day to one week: 24 hours to below 7 days, score 6
• One week to one month: 7 days to below 30 days, score 4
• One to six months: 30 days to below 180 days, score 2
• More than six months: 180 days and more, score 0

Failed deployment recovery time

The DORA band, on the edges of lead time for changes, as the DORA Quick Check gives both the same answers; then the median time from the first failed deployment of a run to the next successful deployment of the same stream, and in brackets the recoveries of the last 30 days; then the recoveries not completed yet, each a run of failed deployments with no success after it, counted, not timed. With none completed, the band and the median are —.

• Recovered in less than one hour: below 1 hour, score 10
• Recovered in less than one day: 1 hour to below 24 hours, score 8
• Recovered in one day to one week: 24 hours to below 7 days, score 6
• Recovered in one week to one month: 7 days to below 30 days, score 4
• Recovered in one to six months: 30 days to below 180 days, score 2
• Recovered in more than six months: 180 days and more, score 0

Change fail rate

The DORA band, the nearest label of the DORA Quick Check's scale; then the failed changes out of the final deployments of the last 30 days, in whole percent, rounded down, and in brackets both counts. A failed change is a failed deployment or an issue labelled failure opened in the window, per repository the larger of the two counts, so an issue about a failed deployment is not counted twice. A failure issue names no service, so a service's row counts its failed deployments only.

• 0%: below 10%, score 10 to 9.1
• 20%: 10% to below 30%, score 9 to 7.1
• 40%: 30% to below 50%, score 7 to 5.1
• 60%: 50% to below 70%, score 5 to 3.1
• 80%: 70% to below 90%, score 3 to 1.1
• 100%: 90% and more, score 1 to 0

Deployment rework rate

The DORA band, on the six points and edges of change fail rate, as the DORA Quick Check scales both the same; then the rework deployments out of the successful deployments of the last 30 days, in whole percent, rounded down, and in brackets both counts. A rework deployment is a successful deployment that is the first success of its stream after a failed deployment, or that happened while an issue labelled failure of its repository was open; it is counted once. A failure issue names no service, so a service's row counts the first kind only. DORA's question is "Approximately what percentage of deployments in the last 6 months were not planned but were performed to address a user-facing bug in the application?", but forsgren measures the last 30 days, like its other four metrics.

• Rework of 0%: below 10% of the deployments, score 10 to 9.1
• Rework of 20%: 10% to below 30% of the deployments, score 9 to 7.1
• Rework of 40%: 30% to below 50% of the deployments, score 7 to 5.1
• Rework of 60%: 50% to below 70% of the deployments, score 5 to 3.1
• Rework of 80%: 70% to below 90% of the deployments, score 3 to 1.1
• Rework of 100%: 90% and more of the deployments, score 1 to 0

Scores

The scoring view shows each metric's score, 0 to 10, and Overall Performance, the mean of the scored metrics, to one decimal. The Numbers and scoring page, when it is shown, has the number and the score of each metric in one cell. Scores follow the DORA Quick Check (dora.dev), © Google LLC, CC BY 4.0.

Each metric's levels above show the score they give; change fail rate and deployment rework rate are scored per whole percent, so their level shows the range of scores its percentages give.

Issues pages

Days are in UTC, weeks run Monday to Sunday, months and years follow the calendar, and a week that spans two months is in both.

Open is the issues open at the end of the period. Total is the issues created up to the end of the period, open or closed; a reopened issue is not created again. Open / Total is Open out of Total, in whole percent, rounded down, and a dash when Total is 0.

New, Completed, Not planned, Duplicate and Other count what happened in the row's period (UTC): New is the issues created; Completed, Not planned and Duplicate are the issues closed with that reason; Other is the issues closed with no reason, or with a reason forsgren does not know, so every close is counted in exactly one of the four. A reopen is counted in none of them; it only puts the issue back into Open.

Lead time is the median time from an issue's creation to its Completed close, over the issues completed in the row's period; Not planned, Duplicate and Other closes are not counted. A reopened issue is measured from its creation to the close in that period. Bugs lead time is the same over the issues that carry the GitHub label bug, and shows — (incomplete) on the same rule as Open bugs. A dash means no issue was completed in the period.

Open bugs is Open counted over the issues that carry the GitHub label bug, as the label is at the latest collection, so adding or removing the label moves the issue's whole history.

When the bug list of a repository is too long to read in full (the read stops at 10,000 issues), Open bugs shows — (incomplete) instead of a number in every row, because a partial count would look complete. The number returns by itself after a complete read.

An arrow after Open and after Open bugs shows which way the count moved from the end of the period before: red when it rose, green when it fell, and grey when it did not change (blue after Open bugs, where a count of 0 open bugs is green too). Red and green mean rose and fell, not worse and better. A day is compared with the day before, a week with the week before, a month with the month before and a year with the year before; the oldest row of each kind is compared with the count just before its period, even when that period is outside the rows shown.

Two limits: a reopen is dated when the collection sees it, not when it happened, so it can fall in a later period than the real one; and when a repository has more issues than the one full read takes (it stops at 100 pages of 100 issues), its older issues are missing and its historical Total stays incomplete. The — (incomplete) note covers Open bugs and Bugs lead time only.

Each optional page has a key in forsgren.config.yml: issues_page, days_page, numbers_scoring_page and history_page. A key takes true (the page is generated and in the menu), unlisted (generated, with no menu entry, and search engines are asked to skip it) or false (the page is not generated). An unlisted page can still be opened by its address. By default the Issues page is listed (issues_page: true), the Daily page is not generated (days_page: false), and the History page and the Numbers and scoring page are unlisted (history_page: unlisted, numbers_scoring_page: unlisted). To put the Daily page in the menu, set days_page: true and run forsgren again to regenerate the report. The Numbers and scoring page puts each metric's number and its score in one cell, written number · score, with a dash where there is no data.

History page (beta)

The History page shows the five metrics and Overall Performance for each period, the oldest on the left. The periods are the calendar half-years (January to June, July to December, UTC) that history_days reaches back, and Last 6 months, the newest column, which runs up to the render time from 180 days before it, so it overlaps the current half-year. A period is a column only when some row has data for it. While only the last 6 months have data, a line under the heading gives the first deployment and the day the first half-year appears. dora_days does not change this page.

Every period is banded as 180 days, DORA's standard, with the edges of 180 days at a working day of 8 hours: weekly to monthly from 6, daily to weekly from 30, hourly to daily from 180 and on demand from 1441. A half-year has 181 to 184 days and the count is the period's own count, not rescaled to 180, so it can read higher than the same pace over exactly 180 days, by at most 3%.

A cell is the number and its score, written number · score, as on the Numbers and scoring page. The Trend chart draws the score of each period, 0 to 10, 10 at the top, the same scale in every chart; a period without data is a gap in the line, never a zero, and a period alone between gaps is a dot. The Trend column is shown from two periods on.

A dash means no data: nothing was deployed yet in that period, or the collection has not read the history back that far yet. To read further back, raise history_days, up to 1825 (5 years); the page fills in over the next daily runs. The lead time of older periods can be a dash, because the commits of older deployments may not be stored. The change fail rate of an old period can count a failure issue that lost its label long ago, because the catch-up of withdrawn failure issues covers only the dora_days window.

The History page is unlisted by default (history_page: unlisted): it is generated and can be opened at history.html, but it has no menu entry and search engines are asked to skip it. Set history_page: true to put it in the menu, or history_page: false to not generate it.

Settings page

The Default column of the settings page is the value used when forsgren.config.yml does not set the key. A current value followed by (not set) means the file does not set the key, so the default applies; a current value without it is set in the file, even to the default's value.

auto_update_level is the largest step of a forsgren update that merges itself; a larger one is left for you. By what a release asks of an installation, a patch release is fixes only, with nothing new for the installation to do or see; a minor release is new behaviour, or anything that asks the installation for something (a permission, a secret, a file, a config key); a major release is one where an installation that does nothing would stop working.

• patch: merges patch updates only
• minor: merges minor and patch updates
• major: merges major, minor and patch updates. It does not mean a major release is safe: nothing checks a release against this installation's own data.