SLA Rule Pause Conditions

Last updated: October 20, 2026

Overview

A pause condition is an optional part of an SLA rule that stops the SLA clock while something about the incident is true—for example, while nobody owns it, or while it is on hold—and starts the clock again on its own when that stops being true. It keeps SLA time a measure of the time your team could act on an incident, so a run is not marked late for time it spent waiting.

An SLA rule measures how long your team takes to respond to an incident. It starts counting when its Start condition is met, stops when its Finish condition is met, and compares the time in between to a time goal from the rule's SLA Profiles. Each measurement is a run. A pause condition sits between Start and Finish and decides when a run waits.

You also choose what happens when the pause ends: the same run carries on with its deadline pushed out by the paused time, or the run ends as Stopped and a new run starts with a fresh time goal. Pause conditions are set up in the new UI under Configuration > AUTOMATION > SLA; the classic view's SLA editor shows the same pause card.

In short

Roles and Access

Pause conditions are configured by SOC administrators, because they change how every incident covered by a rule is measured. The SLA page and every action on it, including opening the list of rules, need the Administrator permission in your role. To check a role, open Global Settings > Organization Management > Roles and select the role: Administrator is a switch below Access Type when the access type is General. Analysts do not configure anything: they see the effect of a pause on the incidents they work, as described in The Analyst View of an Incident.

Opening the SLA Page

The SLA page lists every SLA rule and is where you add, edit, and publish them.

1. In the sidebar, open Configuration.

2. Under AUTOMATION, select SLA.

3. On the SLA tab, select a rule to open it, or select Add SLA, enter an SLA Name, and select Save to create one.

The pause condition belongs to the rule's Time Measurement Conditions, between Start counting time when and Finish counting time when. To change a live rule, select Edit first; your changes stay in a draft until you select Go Live.

Adding a Pause Condition

Add a pause condition when part of an incident's life should not count against its SLA.

1. Under Time Measurement Conditions, choose a Start counting time when condition—for example, Incident is Assigned—and a Finish counting time when condition, such as Incident First Time Closed.

2. Select + Add pause condition. The Pause counting time while card opens, with the hint "Add a condition above to define when this SLA pauses."

3. Select + Field. A condition row appears with a field, an operator, and a value.

4. Choose the field, the operator, and the value. For example, to pause while nobody owns the incident, choose Incident is Assigned, =, and is false.

5. Optionally, add more rows with + Field, or a nested set of rows with + Group, as described in Combining Conditions.

6. Under When resumed, choose Continue this run or End it and start a new run. See Choosing What Happens When the Pause Ends.

7. Read the summary sentence at the bottom of the card to check that it says what you mean.

Pause Condition Fields

A pause condition can test these incident fields. The editor shows them as one flat list; the kinds below only make the table easier to scan.

The operators and values depend on the field. Incident is Assigned offers = and != with is true or is false. Incident Status offers in and not in with one or more of Open, In Progress, On Hold, and Closed. Incident Severity offers Critical, High, Medium, Low, and Informational.

Combining Conditions

Several rows let one pause condition cover more than one waiting state. Between two rows, choose AND (pause only while both are true) or OR (pause while either is true). + Group adds a nested set of rows with its own AND or OR, for a condition such as "unassigned, or on hold and low severity." The summary sentence shows nested groups in parentheses.

When you point at a row, a copy button and a delete button appear at its right. To remove the pause condition entirely, select × at the top right of the card; the dashed + Add pause condition row comes back. A card with no rows in it is saved as no pause condition.

Choosing What Happens When the Pause Ends

When resumed decides whether the time before and after a pause belongs to one measurement or two. Choose it by asking what the SLA is for.

The summary sentence on the card changes with the option. With Continue this run it reads: "Resumes automatically when that stops being true — this run continues where it left off, with its deadline and alerts pushed out by the paused time." With End it and start a new run it reads:

A new run passes through the rule's Start condition again, so it starts only if the incident still meets it. Because its time goal is chosen again, a change made while the incident was paused—a new severity, for example—can give the new run a different goal.

Validation Messages

The pause card checks your condition as you build it, so a rule does not go live with a pause that simply repeats its Start or Finish, or with a row left half-finished.

When you select Go Live with a problem still on the rule, a Please fix the highlighted issues dialog lists it. For a pause condition, the messages are "The pause condition must be different from the Start and Finish conditions." and "Pause condition 'in/not in' conditions cannot have an empty selection." The second one appears when an in or not in row has no values chosen.

Publishing the Rule

Publishing makes the pause condition apply to incidents; until then it exists only in the draft.

1. Check that the editor shows Saved next to SLA Rules.

2. Select Go Live.

3. In Confirm SLA Changes, select Go Live.

Pause Behavior on Incidents

A pause is evaluated every time a relevant incident field changes, so a run pauses and resumes without anyone touching the SLA.

• While paused, the run's status is Paused and its clock does not move. The Planned End stays where it was until the run resumes.

• On resume with Continue this run, the run returns to its active status, keeps its run number, and its Planned End moves out by the time it spent paused.

• On resume with End it and start a new run, the paused run ends with the status Stopped. Its Actual End is the moment it paused, so it keeps the time it actually ran. A new run starts with the next run number.

• A run marked Breached never pauses and never starts a new run. A run is marked Breached when the SLA check finds it still open, and not paused, past its Planned End; no alert has to be set up for this. Once a run is Breached, unassigning or putting the incident on hold changes nothing: the run stays Breached until the Finish condition ends it as Overdue. A pause cannot be used to hide a response that is already marked late.

• A run that is paused when its deadline passes is not marked Breached while it stays paused. When it resumes, its deadline moves out by the time it spent paused, or, with End it and start a new run, it ends as Stopped.

• Finished runs do not change. A run that has ended as Succeeded, Overdue, or Stopped keeps its result whatever happens to the incident later.

• Stopped runs do not trigger anything. No playbook action or notification runs when a run ends as Stopped, and Stopped runs are not counted as outcomes in the reporting module, which reports only real results—succeeded, overdue, and breached runs.

• Removing a pause condition from a live rule and publishing it resumes any paused runs the next time they are evaluated, with their deadlines extended by the time they spent paused.

Monitoring Runs in the Runtime Log

The Runtime Log is the record of every SLA run on your incidents, and it is where you confirm that a pause condition behaves as you intended. Open it from the Runtime Log tab on the SLA page.

With End it and start a new run, the first run ends as Stopped when the incident is reassigned, and a second run starts with its own goal and deadline:

With Continue this run, the same run resumes and its deadline moves. In this example the run paused for about two minutes, and its Planned End moved from 01:17 to 01:19:

A run that reaches its Finish condition after its deadline ends as Overdue with the End reason Finished, and its breach alert appears under Playbook Runtimes. The Stopped runs below it ended at a pause, well before their deadlines.

An open run that has been marked late shows Breached, with its breach alert under Playbook Runtimes and no End reason yet. A pause does not apply to it. In this example, the incident in the bottom row was unassigned after its run was marked Breached: the run is still Breached and still Run 1, and no new run started. The two rows above it belong to another incident, whose first run paused and ended as Stopped in the usual way.

The Analyst View of an Incident

The incident's SLA widget shows each SLA rule measuring the incident, so an analyst can see at a glance whether the clock is running, paused, or late, and why.

• The status line shows the run's status, the time counted so far, and its goal, for example Paused — Elapsed: 16m 29s · Goal: 30m.

• Paused while: names the condition that is pausing the run, in the rule's own words, for example Paused while: Incident is Assigned = false.

• + Run 2 starts on resume appears on a paused run when the rule starts a new run on resume, so you know the current run will end as Stopped.

• A Run chip, such as Run 2, appears once a rule has measured the incident more than once.

• Earlier runs are listed under the current one as "Run 1 · Stopped · 16m / goal 30m", followed by the pause condition for a stopped run. Up to three earlier runs are shown; when there are more, +N earlier runs shows the rest, and Show fewer runs hides them again. Hover over an earlier run's line for its Started, Ended, and Goal, and for a stopped run, Stopped while.

• The widget's header reads Total SLAs: 1 · 2 runs once any rule has run more than once on the incident.

• A Breached run moves to the Alerts tab and is counted in the alerts badge at the top right.

Pause Conditions in the Classic View

Pause conditions are set up in the new UI, and the classic view's SLA editor shows the same pause card. Open Configuration in the classic view, then the SLA list, and open a draft rule: + Add pause condition sits between Start counting time when and Finish counting time when, and the card offers the same + Field, + Group, and When resumed choices.

Sample Cases

These three configurations cover the waiting states SOC teams most often pause on.

A fresh clock for each owner. Start: Incident is Assigned. Finish: Incident First Time Closed. Pause: Incident is Assigned = is false, End it and start a new run. When an owner gives the incident back to the queue, the run pauses; when someone picks it up, the old run ends as Stopped and the new owner gets a full time goal.

Waiting time does not count. Start: Incident is Assigned. Pause: Incident Status in On Hold, Continue this run. While the incident is on hold, waiting for the requester, the clock stops; when it comes off hold, the same run continues with its deadline pushed out by the hold time.

Either waiting state. Pause: Incident is Assigned = is false OR Incident Status in On Hold. The run pauses while the incident has no owner or is on hold, and resumes only when neither is true.

FAQs

Can a pause hide a Breached run?

No. Once a run is Breached, it never pauses and never starts a new run. It stays Breached until the Finish condition ends it as Overdue.

Does reassigning an incident from one analyst to another pause it?

Not with Incident is Assigned = is false. A direct handover never leaves the incident unassigned, so the run continues.

What happens to a paused run when the rule changes?

The change applies the next time a relevant field changes on the incident. If you remove the pause condition and publish, paused runs resume with their deadlines extended by the time they spent paused.

Why is + Add pause condition greyed out?

The rule has no Start counting time when condition yet. Choose one first.

Do Stopped runs appear in SLA reports?

No. The reporting module counts succeeded, overdue, and breached runs. A Stopped run appears in the Runtime Log and on the incident.