SLA Breached even though Incident was on HoldIssue The SLA "P3 Incident Resolution Data AM MNT" was breached even though the incident was set to "On hold" till it moved to "Resolved". According to the defined pause conditions, the SLA should have paused in this scenario. The Business elapsed on the task sla record did not match the timeline.ReleaseNACauseReview of one of the impacted example incidents and related task SLAs showed the Business elapsed on the task sla record: 14 Hours 2 Minutes SLA timeline does not match above. Business elapsed on timeline is 1 second From the timeline and the incident activities, we can see it went into pause a second after getting created. The time of pause in US PST 02/01/2025 16:40:00 The logs showed at this time that there were 2 executions of the business rule, Run Slas, both started at the same time but seconds apart txid=237e0514c363 started later (2025-02-01 16:40:01 (670) ) but completed first and so paused the task sla txid=6b7e0ddcc3e started earlier (2025-02-01 16:40:01 (374)) but completed after above. It most likely started executing with stale data and so when it executed it resumed the sla. In a previous case, the customer was given a solution to add incident table to the below property to prevent stale read issues with their SLA's. The customer implemented the solution but subsequently reported that the issue still occurs. System property "com.snc.sla.get_task_from_db': https://instance_name.service-now.com/nav_to.do?uri=sys_properties.do?sys_id=04996bb573200010491d235f04f6a74c It was noted that the value field has a space after the comma. Value: sc_req_item, incident ***There should be no spaces after the comma when adding tables in the value of this property. The above is most likely why the property did not resolve the issue and force a re-query to the database when Run SLA's executes.ResolutionReview the property: 'com.snc.sla.get_task_from_db' and ensure that there are no spaces after the comma in the value field.