Before You Change the SLA Target, Check What the Clock Is Counting

A red service report creates an immediate temptation: give the team more time, or pause the clock in more situations. Either edit might improve the display. Before making it, I'd want to know whether the timer is measuring the promise people think they agreed to.

An SLA, or service-level agreement, expresses a service commitment. Jira Service Management translates it into eligible requests, targets, calendars, and conditions that start, pause, and stop measurement. Those settings can describe a slow service accurately or count a different promise from the one everyone has in mind. [1][2]

The distinction is easier to understand with hours on a timeline than with another discussion about whether the report feels fair.

Eight hours under which clock?

Here is a hypothetical agreement: resolve an eligible request within eight business hours, Monday through Friday, 09:00–17:00 in the service's time zone, excluding an agreed pause while necessary customer information is outstanding. Assume no holidays and no daylight-saving change during the example.

The request arrives on Friday at 16:00. On Monday at 10:00, the team asks the customer for information it genuinely needs. The customer responds at 12:00, and the request is resolved at 15:00.

The customer experienced a much longer elapsed wait, but this specific SLA counts five hours. That isn't a judgment about whether the customer's experience was good. It tells us what this particular commitment measures. Calendars and pause conditions implement different parts of that calculation. [3][4]

Now we can ask a precise question about an unexpected result. Did the clock include the weekend? Did it pause before the information was requested? Did it resume when the response arrived? One discrepancy points toward a more useful investigation than simply raising eight hours to twelve.

Internal waiting may still be your responsibility

Change one fact in the example. Between 10:00 and 12:00 on Monday, the service desk was waiting for an internal approver, not for the customer. Under our stated agreement, those two hours count. The total becomes seven hours.

The employee handling the request may have been unable to proceed, but the organization still owed the service. Moving the request into a convenient waiting status shouldn't silently turn that dependency into excluded time. Whether a pause is legitimate comes from the agreement and the actual circumstance, not from who finds the red indicator uncomfortable.

A different agreement could treat waiting differently. That is why the timeline needs its assumptions alongside it. It is a teaching example, not a rule that all SLAs should use the same calendar or pause.

A repaired measurement and a faster service are different results

If the configured calendar is wrong, correcting it is useful work. Preserve an account of the earlier behavior and explain any reporting change. Jira's treatment of existing SLA cycles can depend on which goals and conditions are edited, so the applicable product behavior matters before a change is rolled out. [1]

If the clock is right, however, its uncomfortable result is information about the service. In our case, an internal approval delay may deserve attention. Changing the pause condition would conceal that delay without making the approval happen sooner.

The target itself can also be renegotiated when the service, funding, or accepted commitment changes. A twelve-hour promise might be appropriate, but meeting it doesn't show that the team became faster at fulfilling the previous eight-hour promise.

I would keep the timeline after the discussion. It gives the service owner and administrator a shared example of what the agreement means, including the awkward periods. Once they agree on that, they can spend less time defending a color and more time addressing the waiting that actually affects the customer.