Recurrence Rate & MTBI by Project(3.4.5)

A recurring incident is one that reached a done status and was then reopened. This visual shows the recurrence rate per project, the share of the project's incidents that were reopened at least once, alongside the mean time between incidents, the average gap from one incident's creation to the next, so you can see both how often incidents came back and how closely new ones followed each other. An incident here is an issue created as a Bug, Incident, Defect or Problem.

For teams preparing a NIS2 review, reviewers typically ask how often resolved incidents came back. This visual is a starting point for that question.

What you can conclude

• A high recurrence rate with a short mean time between incidents means many resolved incidents came back and new incidents arrive close together; a reviewer could ask whether the fixes reached the underlying cause.
• A low recurrence rate with a long mean time between incidents means few resolved incidents came back and incidents are spaced far apart.
• Comparing recurrence rates across projects shows whether repeat incidents are concentrated in specific areas or distributed across the portfolio.
• The date filter selects which projects are listed, keeping those with incident activity in the period; the recurrence rate and the mean time between incidents are computed over each project's whole incident history, which is what makes a mean time between incidents meaningful at all.

How this chart works

Bar chart showing recurrence rate and mean time between incidents per project. Use the project filter to focus on specific teams.

A gray em-dash in the MTBI column means the project recorded a single incident, so there is no interval to average — a gap needs two incidents to exist. Read it as not measurable, never as a fast-recurring project. A measured 0.0 in the same column is the other end of the scale: two or more incidents whose average gap rounds to under about 72 minutes, the shortest gap the column can show.