Documentation

    {{docApp.userSession.userId}}
    {{docApp.userSession.userName}}
    {{docApp.userSession.email}}
    Issuer : {{docApp.userSession.issuerInstance}}
    Expires : {{new Date(docApp.userSession.validUntil).toLocaleDateString()}}

{{docApp.title}}

{{docApp.description}}

How can we help?

{{docApp.searchError}}
{{product.name}}

Searching in {{docApp.searchFilterBySpecificBookTitle}}

{{docApp.searchResultFilteredItems.length}} results for: {{docApp.currentResultsSearchText}} in {{docApp.searchFilterBySpecificBookTitle}}
Search results have been limited. There are a total of {{docApp.searchResponse.totalResultsAvailable}} matches.

You have an odd number of " characters in your search terms - each one needs closing with a matching " character!

{{docApp.libraryHomeViewProduct.title || docApp.libraryHomeViewProduct.id}}

{{docApp.libraryHomeViewProduct.description}}

  1. {{book.title}}

{{group.title || group.id}}

{{group.description}}

  1. {{book.title}}

{{group.title}}

{{book.title}}
More...

Interpret SLA status using the Within Resolve Time field

This article explains how to interpret SLA status in two different ways: one by viewing the Request List, and the other by using a database column in the h_itsm_requests table. These two ways of looking at SLA status have different purposes.

Introduction

In the Request list, using the column selector, users have the option to expose an indicator called SLT. This indicator provides information about service-level targets using colored dots. The first dot refers to any Response timer set; the second dot refers to a Resolution timer. The colors have various meanings. Clear means Timer not in use. Blue means Ongoing. Green means Target met. Red can mean two things: either At risk of missing target or Breached.

SLT indicator

About the At risk of missing target indicator and requests on hold

If an SLA target (SLT) appears red for a request currently in On Hold status, it should be interpreted as at risk rather than breached. This is because, per standard SLA logic, the timer is paused while a request is on hold. The red indicator should be interpreted as saying that the SLA would be breached if the ticket were to re-enter an active status without any changes to the request circumstances (i.e. changes that could potentially trigger SLA recalculation and result in a new or adjusted SLA target). Therefore, in this scenario, while the red state serves as a useful warning, it does not represent an actual breach during the hold period.

The SLT indicator shows a calculated value

It is important to understand that the SLT indicator is not written to any database field. If you need to access the values from a particular field — for example, for reporting purposes — read on for which fields to use.

The SLT is a calculated value and is displayed, not stored. The SLT is calculated dynamically based on the current date/time and the target date/time, for as long as the timer is running. Once the timer stops, the system uses the values from Within Response Time (the h_withinresponse column) or Within Resolve Time (the h_withinfix column) instead. This dynamic behavior means that these field values only update when the timer ends or when the indicator shows red.

As soon as the indicator becomes red, the value is set in those fields. As explained above, the indicator can become red both when the SLA is at risk of being breached or when the SLA is actually breached (and marked as such permanently).

When is an SLA target considered breached?

Active requests should not be seen as breached. An SLA target should not be considered breached until the SLA timer has stopped.

Furthermore, the SLA timer stopping does not necessarily coincide with the request being resolved or closed. Until the SLA timer has stopped, the SLA status should be considered at risk, but not final. This is because the SLA timer can:

  • Pause (e.g., when the request is placed on hold)
  • Resume
  • Be recalculated based on request updates, status changes, or applied service levels.
  • Be stopped by a workflow. (See the article about timer automations.)

While breach points are tracked in real time, it is possible for a request to still meet the SLA once it has been closed — even if it has appeared at risk or past the SLA target during its lifecycle. This is especially true when factors such as hold times, escalations, or reprioritization come into play.

About the Within Resolve Time database column

The Within Resolve Time field (h_withinfix) helps determine whether a request is within SLA, at risk of breaching it, or has breached it. The values in this field have the following meanings:

Value Meaning Notes
Empty (no value) Within SLA The SLA is active and counting toward the target.
1 SLA met The SLA timer stopped before the target was breached.
0 SLA breached or at risk of being breached This indicates potential SLA breach status, which requires further checking (see below).

For example, consider the following requests, all of which are either at at risk of being breached or in breached status, and all of which have a Request Resolution Timer ID of 0:

  • Request 12345 has a Within Resolve Time field value of 0. Its status is On Hold. The Request Resolve By date/time is after the Date Placed On Hold, so the request is within the SLA target.

  • Request 23456 has a Within Resolve Time field value of 0. Its status is Resolved. (This means it’s active, because being active includes New, Open, and Resolved.). The Request Resolve By date/time is before the current date/time, so the request has breached its SLA.

  • Request 34567 has a Within Resolve Time field value of 0. Its status is On Hold. The Request Resolve By date/time is before the Date Placed On Hold, so the request is at risk of breaching its SLA.

About the Request Resolution Timer ID database column

The Request Resolution Timer ID (h_fixtimeid) applies only when Within Resolve Time = 0 (i.e. when the SLA is either breached or at risk of being breached).

When Within Resolve Time = 0, the Request Resolution Timer ID helps confirm the SLA breach status:

  • If the Request Resolution Timer ID is 0 or empty, this means the SLA timer has stopped and the SLA is permanently marked as breached.
  • If the timer ID has a value other than 0, the SLA timer is still active, indicating the SLA is at risk but not necessarily yet breached.

For active timers when Within Resolve Time = 0:

  • For requests with an active status (i.e. Open, Resolved, or Closed):
    • The SLA is at risk of breach if the Request Resolve By date/time is before the current date/time.
    • The SLA is within target if the Request Resolve By date/time is after the current date/time.
  • For requests with an on-hold status:
    • The SLA is at risk if the Request Resolve By date/time is before the Date Placed On Hold.
    • The SLA is within target if the Request Resolve By date/time is after the Date Placed On Hold.

What about when Request Resolution Timer ID is not equal to 0?

The following considerations apply only when Request Resolution Timer ID has a value other than 0:

  • If Within Resolve Time = 0 and Request Resolution Timer ID ≠ 0, but the request is shown as within target, it means the SLA was previously at risk, but due to changes (such as service level de-escalation), the SLA is now considered within target.
  • If Within Resolve Time = 0 and Request Resolution Timer ID ≠ 0 and the request is shown as missed the target, SLA is at risk — but a breach should only be confirmed once the resolution timer has definitively stopped.

Further information

For information on service levels and configuration, see Service Levels and Service level indicators.

  • Version {{docApp.book.version}}
  • Node {{docApp.node}} / {{docApp.build}}
In This Document