Guide · 29 October 2026

How to measure repeat incidents

Most IT teams can tell you their MTTR. Few can tell you how many of last month's incidents had already happened before. That number, the recurrence rate, shows whether your team is fixing problems or just restarting things. Here is how to measure it from a plain ticket export.

Why MTTR is not enough

Mean time to resolve tells you how fast you put fires out. It says nothing about whether the same fire keeps starting. A team can halve its MTTR by getting very good at restarting the same service every week, and the business is no better off.

Recurrence rate measures the other half: how much of your incident workload is work you have done before. It is the clearest signal that problem management is or isn't working, and it translates directly into hours and money.

Step 1: export the right columns

Export at least six months of incidents from Jira Service Management, ServiceNow, Freshservice or whatever you use. You need:

• Ticket ID
• Opened date and time
• Service (or affected application, configuration item or component)
• Category (or incident type, symptom or classification)

If you also have resolved time, priority and a linked problem ID, export them too. They let you measure MTTR, SLA compliance and how many repeats were ever linked to a problem record.

Step 2: decide what counts as "the same"

The simplest signature that works in practice is service + category. It is crude, but it uses fields every tool has, and it is consistent month to month. Two things make it better:

• Clean the categories. If agents pick "Other" for 40% of tickets, fix the category list first. A short, enforced list beats a long, ignored one.
• Pick the right service level. "Payments" is better than "Production"; "payments-api" is better still if your CMDB supports it.

Step 3: choose a window

A repeat that happens a year later is a different problem from one that happens next Tuesday. Use a window: an incident counts as a repeat if the same signature appeared in the previous N days.

• 30 days is a good default for most service desks.
• 7 days if you want to catch "fixed it, came straight back" failures.
• 90 days for slow-burning issues such as certificate expiries or batch jobs.

Pick one and keep it. A recurrence rate is only useful as a trend.

Step 4: calculate it

In Excel or Google Sheets, put your export in a table with columns Opened, Service and Category, and the window in a cell named Window. Then add a column:

=IF(COUNTIFS([Service],[@Service],[Category],[@Category],
        [Opened],"<"&[@Opened],[Opened],">="&[@Opened]-Window)>0,1,0)

It returns 1 if an earlier incident with the same service and category was opened within the window. Recurrence rate for a month is the sum of that column divided by the number of incidents opened that month.

Or try it right here with your own data. Paste a CSV with opened,service,category (one incident per line). Nothing you paste leaves this page.

Step 5: turn it into hours and money

Multiply repeat incidents by the average hours each one takes, then by a loaded hourly cost. A desk with 120 incidents a month, a 30% recurrence rate and 3 hours per incident spends about 1,300 hours a year on work it has done before. At €45 an hour that is roughly €58,000. The cost calculator on our homepage does this for your numbers.

That figure is what gets problem management funded. "We should do more root cause analysis" rarely survives a budget meeting. "We spend €58,000 a year fixing the same things" usually does.

Step 6: act on what you find

1. Sort service and category pairs by number of repeats. The top five are your problem backlog.
2. Open a problem record for each, with one owner.
3. Publish a workaround as a known error so the service desk can resolve faster while the fix is pending.
4. Track problem linkage: the share of repeat incidents linked to a problem record. Low linkage with high recurrence is the clearest gap to close.
5. Review the trend monthly. A falling recurrence rate is the best evidence that the work is paying off.

Common mistakes

• Counting duplicates as repeats. Five tickets about the same outage are one incident. Merge or link duplicates before measuring.
• Changing the window. Moving from 30 to 7 days will make the number drop overnight without anything improving.
• Chasing a target too early. There is no reliable industry benchmark for recurrence rate; it depends heavily on how you categorise. Measure your own baseline and push it down.

Questions