Understanding Retroactive Start and Retroactive Pause/Stop in SLA (ServiceNow)

ny424436
Mega Contributor

Hi everyone,

I’m trying to understand the concept of Retroactive Start and Retroactive Pause/Stop in SLA within ServiceNow, but I’m a bit confused about how they work in real-world scenarios.

I have a few questions:

  1. What is the exact purpose of Retroactive Start and Retroactive Pause/Stop in SLA?

  2. Under what conditions does Retroactive Start trigger, and how does the system calculate the actual start time?

  3. For Retroactive Pause/Stop, how does ServiceNow determine the correct past time for pause or stop?

  4. In which real-life scenarios should we enable these options, and when should we avoid using them?

It would be really helpful if someone could explain this with a practical example related to a real incident.

Thanks in advance!

1 REPLY 1

Vishnu-K
Kilo Sage

Hi @ny424436 ,

 

These options exist because the SLA engine evaluates conditions at the time a record is saved. But sometimes the condition that should have triggered a start, pause, or stop happened earlier in the past. Retroactive options handle that by looking back at the audit history and applying the correct time.

 

Retroactive Start — Instead of starting the SLA timer from now, ServiceNow looks at the audit log and backdates the start to when the condition was first true. For example if an incident was created 30 minutes ago but the SLA only attached now, Retroactive Start will correctly set the start time to 30 minutes ago rather than the current moment.

 

Retroactive Pause and Stop — Same idea. If the incident moved to Awaiting User Info 2 hours ago but the SLA engine missed that transition, Retroactive Pause will backdate the pause to 2 hours ago so that waiting time is correctly excluded from the elapsed time.

 

Enable these when accurate timing from the true origin or past state changes is important for compliance or reporting. Avoid them if your audit history is incomplete because the calculation depends entirely on accurate historical data.

 

Reference: https://www.servicenow.com/docs/bundle/washingtondc-it-service-management/page/product/service-level...

If it helped you please do mark it as helpful and accept the solution

 

Thanks,

Vishnu