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.

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)
• Between once per hour and once per day: 30 to 240 in 30 days
• Between once per day and once per week: 5 to 29 in 30 days
• Between once per week and once per month: 1 to 4 in 30 days
• Between once per month and once every six months: none in 30 days, 1 and more in 180 days
• Less than once per six months: none in 180 days

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
• Less than one day: 1 hour to below 24 hours
• One day to one week: 24 hours to below 7 days
• One week to one month: 7 days to below 30 days
• One to six months: 30 days to below 180 days
• More than six months: 180 days and more

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 —.

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%
• 20%: 10% to below 30%
• 40%: 30% to below 50%
• 60%: 50% to below 70%
• 80%: 70% to below 90%
• 100%: 90% and more

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.

Scores

The scoring view shows each metric's score, 0 to 10, and Overall Performance, the mean of the scored metrics, to one decimal. Scores follow the DORA Quick Check (dora.dev), © Google LLC, CC BY 4.0.

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.

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.

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, grey when it did not change. 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.

The Issues page and the Daily page are shown or hidden with issues_page and days_page in forsgren.config.yml. By default the Issues page is shown (issues_page: true) and the Daily page is hidden (days_page: false); days_page: true brings the Daily page back. A hidden page is not generated and has no entry in the menu. To add the Daily page, set days_page: true and run forsgren again to regenerate the report.

Settings page

The Default column of the settings page says whether the default applies: True when forsgren.config.yml does not set the key, so the current value is the default, and False when the file sets it, 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.