SLA Repair for incidents with on hold reason

[Community Alums]

We had a pause condition looking at on hold reasons to pause the SLA.
Then we changed these on hold reasons but hadn't immediately changed the pause condition which caused us to run the repair for historical incidents.

But we ran it for a whole month of incident task resolution SLAs instead of the time frame from which the on-hold reasons had changed. Now, some older incidents with old on hold reasons was recalculated wrongly and are being shown as breached after this repair.
I believe it is due to the fact that the old on-hold reason is not there in SLA definition pause condition so the pausing is not happening for these old incidents.
Is this the reason or Can I fix it by some other method?

[Dr Atul G- LNG]

Hi @Community Alums 

Technically, there's no way to update the SLA inline unless you change the incident to a different state and then bring it back to "On Hold". Only then will the SLA recalculate based on the new conditions.

We faced the same issue — we had to wait until the incident state changed and was then returned to "On Hold" in order for the updated SLA conditions to take effect.

[IsabellaA]

Yes your understanding is correct. When you ran the SLA repair for a wider historical range, the system re-evaluated older incidents using the current SLA definition. Since the old on-hold reasons were removed from the pause condition, those historical records no longer qualify for pausing, so their SLAs appear breached.

Unfortunately, SLA repair always recalculates based on the current definition — it doesn’t respect historical pause logic. The cleanest options are:

• Re-add the old on-hold reasons temporarily to the pause condition, run a targeted SLA repair for the affected records, then remove them again.

• Or revert from backup / accept the recalculation if reporting accuracy isn’t critical for past data.

This is similar to recalculating turnaround times in real-world repair workflows — if the pause criteria change midstream, older jobs can look overdue even when they weren’t. We see this often when tracking service timelines in industries like appliance repair .

In short: yes, it’s expected behavior, and the only fix is aligning the pause condition with the historical data before repairing.