Non of our SLA timers are pausing when they should. Has anyone else had this issue?
+4Hi there,
SysAid Copilot is here with our AI Magic!
Here is the response we thought might assist you:
SysAid Copilot is here with our AI Magic!
Here is the response we thought might assist you:
## SLA Timers Not Pausing
Yes—this can happen, and it’s usually due to configuration details in timers, statuses, or operating times. Here’s a quick checklist to help you pinpoint and fix it:
### 1) Verify the timer logic
- Go to: Settings > Service Desk > Timers.
- Open each relevant timer and confirm:
- The Expression/Filter matches the records you expect (e.g., Status = Awaiting User, Awaiting Vendor, On Hold).
- The “Count only during operating times” option is set as intended.
- The statuses included/excluded align with when the clock should run or pause.
Tip: If you expect the clock to pause on certain statuses, make sure the timer’s condition does NOT match those statuses while they’re active. Alternatively, use separate timers per phase with mutually exclusive conditions.
### 2) Check SLA/SLM and Due Date timers
- Settings > Service Desk > SLA/SLM:
- Confirm which statuses pause the Due Date (SLA) clock if you rely on due-date pausing rather than a custom timer.
- Ensure escalation/alerts are tied to the correct timer/field.
### 3) Confirm operating times and time zone
- Settings > General > Operating Hours: ensure they reflect your working hours.
- Verify the account time zone; mismatches can make timers appear to run when they shouldn’t (common after DST or TZ changes).
### 4) Test on fresh sample tickets
- Create two test incidents:
- Move one to a “pause” status (e.g., Awaiting User) and wait a few minutes.
- Keep the other in an “active” status.
- Compare the timer fields and due-date behavior. This isolates config vs. data history issues.
### 5) Validate reporting columns
- If you’re judging from a report, ensure the report column maps to the exact timer name/field you intend. Mismatched columns can make it seem like pause isn’t working.
### 6) Common pitfalls to check
- Multiple timers overlapping with conflicting conditions.
- Status labels changed but timers still reference old values.
- Escalation rules or automation updating status back and forth, causing unexpected timer runs.
- Timers set to count all time instead of working hours.
If you can share:
- One or two SR numbers showing the issue,
- The timer names and their expressions,
- Which statuses should pause the clock,
I can help pinpoint the misconfiguration quickly. If this is urgent or you prefer hands-on assistance, please open a Service Record from the chat page so Support can review your environment settings.
Yes—this can happen, and it’s usually due to configuration details in timers, statuses, or operating times. Here’s a quick checklist to help you pinpoint and fix it:
### 1) Verify the timer logic
- Go to: Settings > Service Desk > Timers.
- Open each relevant timer and confirm:
- The Expression/Filter matches the records you expect (e.g., Status = Awaiting User, Awaiting Vendor, On Hold).
- The “Count only during operating times” option is set as intended.
- The statuses included/excluded align with when the clock should run or pause.
Tip: If you expect the clock to pause on certain statuses, make sure the timer’s condition does NOT match those statuses while they’re active. Alternatively, use separate timers per phase with mutually exclusive conditions.
### 2) Check SLA/SLM and Due Date timers
- Settings > Service Desk > SLA/SLM:
- Confirm which statuses pause the Due Date (SLA) clock if you rely on due-date pausing rather than a custom timer.
- Ensure escalation/alerts are tied to the correct timer/field.
### 3) Confirm operating times and time zone
- Settings > General > Operating Hours: ensure they reflect your working hours.
- Verify the account time zone; mismatches can make timers appear to run when they shouldn’t (common after DST or TZ changes).
### 4) Test on fresh sample tickets
- Create two test incidents:
- Move one to a “pause” status (e.g., Awaiting User) and wait a few minutes.
- Keep the other in an “active” status.
- Compare the timer fields and due-date behavior. This isolates config vs. data history issues.
### 5) Validate reporting columns
- If you’re judging from a report, ensure the report column maps to the exact timer name/field you intend. Mismatched columns can make it seem like pause isn’t working.
### 6) Common pitfalls to check
- Multiple timers overlapping with conflicting conditions.
- Status labels changed but timers still reference old values.
- Escalation rules or automation updating status back and forth, causing unexpected timer runs.
- Timers set to count all time instead of working hours.
If you can share:
- One or two SR numbers showing the issue,
- The timer names and their expressions,
- Which statuses should pause the clock,
I can help pinpoint the misconfiguration quickly. If this is urgent or you prefer hands-on assistance, please open a Service Record from the chat page so Support can review your environment settings.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
