What is the purpose of Stop Condition in SLA and when should it be used in ServiceNow?

[ny424436]

I have a question regarding the Stop Condition in SLA within ServiceNow and would like to understand its actual purpose and usage.

As per my understanding, the stop condition defines when an SLA should end (for example, when an incident is resolved or closed).

However, I would like clarification on the following:

1. What is the exact purpose of the stop condition in SLA?
2. In which scenarios should we configure a stop condition?
3. How does the stop condition differ from pause condition and cancel condition?
4. What happens if a stop condition is not properly defined in an SLA?

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

Thanks in advance!

[Vishnu-K]

Hi  @ny424436  ,

Let me break this down for you.

The Stop Condition in an SLA definition is what tells the SLA engine to permanently end the SLA timer and mark the SLA task as Completed. Once the stop condition is met, the timer stops for good and the system checks whether the time taken was within the target or not, and marks it as Met or Breached accordingly.

You should configure a stop condition whenever the SLA has a clear endpoint tied to the record's lifecycle. The most common example is setting the stop condition as State = Resolved or State = Closed for a resolution SLA. For a first response SLA you might stop it when the state moves away from New, meaning someone has picked it up.

Coming to how it differs from pause and cancel , the pause condition temporarily holds the timer and it resumes once the pause condition is no longer true, for example when you are waiting on the user and put the incident in a Awaiting User Info state. The cancel condition voids the SLA entirely as if it never applied, which is usually used when the incident gets transferred to a different team or category that has a different SLA. The stop condition is different from both because it actually completes the SLA and records the final outcome.

If a stop condition is not properly defined, the SLA timer keeps running even after the incident is resolved. This leads to false breaches, wrong SLA reports, and SLA tasks that never reach the Completed stage. So it is important to always align the stop condition with your incident closure or resolution state.

Practical example , for a P2 incident with a 4 hour resolution SLA, the start condition would be State = New, the stop condition would be State = Resolved or Closed, and the pause condition could be State = Awaiting User Info. When the incident moves to Resolved, the stop condition fires, the timer stops, and the SLA is evaluated and closed.

You can refer to the official docs here: https://www.servicenow.com/docs/bundle/washingtondc-it-service-management/page/product/service-level...

Hope this clears it up.

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

Thanks,

Vishnu

[Ankur Bawiskar]

@ny424436 

my thoughts

1. Purpose of stop condition: Defines when the SLA ends and is marked completed (e.g., incident resolved/closed).

2. When to configure it: Use when you want a clear endpoint, like State = Resolved or State = Closed

3. Stop vs pause vs cancel:

   • Stop: Completes SLA (e.g., incident resolved).

   • Pause: Temporarily halts timer (e.g., incident On Hold).

   • Cancel: Terminates SLA entirely (e.g., invalid or unassignable record).

4. If not defined properly: SLA keeps running or misbehaves, causing incorrect tracking and metrics.

5. Practical example: Incident with 4‑hour SLA stops counting as soon as State = Resolved; otherwise it stays in progress or paused

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏