Configuring SLA for Different Time Zones in Jira: How to Deliver Global Support Effectively

[#1]

Your EMEA support team recorded the lowest SLA performance in the quarterly report. Upon reviewing several breached tickets, you find a consistent pattern: each was transferred from another region after EMEA working hours had ended.

The team was not slow; the timer continued to count hours when no one responsible for the request was available.

For global support teams, SLA tracking becomes challenging when tickets move across regions. A target like “first response within four business hours” is clear until a ticket transitions between Canada, Poland, and Singapore. Which business hours should apply in these cases?

👀 Where global SLA tracking usually breaks

The first issue is straightforward: the SLA timer runs outside the responsible team’s working hours. As a result, a ticket may appear close to breach before the next regional team begins its day.

The second issue arises when administrators use a single extended global calendar. If the calendar includes all regions’ working hours, it may count nearly the entire day as working time. While this approach simplifies reports, the metric no longer reflects any team’s actual availability.

The third problem is reporting. When tickets from several regions are measured against the same fixed schedule, you may compare teams that were never working under the same conditions. A regional SLA chart can then reflect calendar design rather than actual service performance.

This is why multi-timezone SLA configuration is not only a calendar task. It is also a question of responsibility: whose working time should the SLA follow while the ticket is being handled?

🗓️ What native JSM calendars already handle well

Jira Service Management already allows administrators to create SLA calendars for their service project or service space.

From the SLA area, you can create a calendar, set its time zone, define working days and hours, add multiple working intervals per day, and exclude holidays. For example, you can configure a support calendar that works from 09:00 to 12:00 and from 13:00 to 17:00, excluding the lunch break.

These calendars are available when configuring SLA goals. For a service model with one fixed support window, this may be enough. A team that provides support only during UK business hours can create a UK calendar and apply it to the appropriate SLA goal.

The challenge arises when the same type of ticket is moved between people or groups with different schedules. A fixed calendar can describe one operating window. It does not solve the broader operational question: what should happen to the timer when responsibility moves from one region to another?

🧭 Step 1. Decide what your SLA is actually measuring

Before creating calendars, decide which clock should matter in your process.

For some customer contracts, the commitment is based on the customer’s service window. A European customer may expect support during European business hours, even if the provider has agents in several regions.

For internal IT, development support, escalation flows, or follow-the-sun delivery, the more practical model is often different: the SLA should reflect the team's working hours.

This distinction matters because Multiple-scheduler SLA in SLA Time and Report is designed around the responsible assignee or group schedule. It is not simply a “Customer Region” field that automatically selects a customer calendar.

A region field can still be useful for routing and reporting. For example, Support Region = APAC can help you analyze APAC results later. But the schedule used for SLA calculation should match the way responsibility is actually assigned in the workflow.

⚙️ Step 2. Create a work schedule for each operational region

In SLA Time and Report for Jira, work schedules define when SLA time is counted. Instead of counting every elapsed hour, the app counts only the time inside the selected working schedule.

For a global support setup, you might create schedules such as:

Work schedule	Time zone	Working hours	Holidays
Canada Support	Toronto local time	Mon–Fri, 09:00–17:00	Canadian non-working days
Poland Support	Warsaw local time	Mon–Fri, 09:00–18:00	Polish non-working days
Singapore Support	Singapore local time	Mon–Fri, 09:00–18:00	Singapore non-working days

In the app, open the SLA configuration area, go to Work Schedules, and add the schedules your service model requires.

For each schedule, define the time zone, working days, working hours, breaks, and holidays. You can also define the business day for SLA goals. By default, 1d equals 8 working hours, but this can be adjusted if your service agreement uses a different definition.

🔁 Step 3. Configure one SLA goal that can follow the responsibility

The older approach to multi-timezone support often required separate SLA configurations for each region and a custom field such as Location. That can work, but it becomes difficult to maintain when teams change, people are reassigned, or a ticket crosses several handoffs.

With the Multiple-scheduler SLA type in SLA Time and Report, you can use multiple working schedules within a single SLA configuration.

The setup logic is:

1. Open SLA Configuration Manager.
2. Select Add SLA configuration.
3. Choose multi-schedule as the SLA goal type.
4. Connect the relevant users or groups to their work schedules.
5. Configure the SLA conditions and goals.

When a ticket is assigned to a support agent in Canada, SLA time is calculated according to the Canada schedule. If it is later reassigned to a responsible agent or group in Poland, the calculation adapts to the Polish schedule. Time outside the Polish team’s working hours is not treated as active working time for that part of the ticket lifecycle.

This avoids duplicating the same First Response or Resolution SLA across regions to account for calendar differences.

⏱️ Step 4. Keep SLA conditions separate from regional schedules

A calendar answers the question: when should time count?

SLA conditions answer a different question: what event starts, pauses, or stops the timer?

For global support, two common examples are:

SLA measure	Start condition	Pause condition	Stop condition	Goal example
First Response Time	Request created	Not usually needed before first reply	First public agent response	P1: 30 minutes; P2: 4 working hours
Resolution Time	Request created or accepted by support	Waiting for customer	Resolved	P1: 4 working hours; P2: 1 business day

Your goals may vary by priority, request type, or service contract. The important point is that regional schedules should control counted working time, while SLA goals should still reflect the actual commitment you promised.

For example, moving a ticket from Canada to Poland may change which hours are counted. It should not silently change a P1 target from 30 minutes to four hours unless your SLA configuration explicitly requires that.

✅ Step 5. Test handoffs before relying on the report

A global SLA setup should not be considered complete after the calendars are saved. Test the transitions that usually create confusion.

Create a small set of test tickets and check these scenarios:

1. Create a ticket shortly before the Canada team finishes work, then assign it to Poland outside Polish working hours.
2. Reassign a ticket on a date that is a holiday for one region but a working day for another.
3. Move a request between two groups and confirm that the timer follows the responsible schedule.
4. Check both an active and a completed ticket in the report to confirm that the elapsed and remaining times match the expected working windows.

This test is especially important for First Response and Resolution SLAs because false breaches can quickly become noisy alerts, inaccurate dashboards, and unnecessary escalations.

📊 Step 6. Report by region without mixing different stories

Once the timer reflects actual working hours, the next step is to make the report understandable.

In SLA Time and Report, the SLA Grid can be used for ticket-level review: SLA status, elapsed or remaining time, and target dates. This is useful when investigating individual breaches or checking whether a handoff behaved correctly.

For trend analysis, use Met vs Exceeded or Met vs Exceeded per Criteria charts. The latter can break results down by Jira fields or other criteria such as assignee, organization, severity, or a custom field created for operational reporting.

You can also add SLA charts to a Jira Dashboard as gadgets, so team leads can monitor Met vs Exceeded results without opening a separate report every day.

Finally, alerts should follow the same operational model. A pre-breach Slack notification is useful only when it reaches the team currently responsible for the issue and when the timer itself is based on their actual working time. Otherwise, the notification only announces a calendar problem.

Final thoughts

Global SLA problems rarely start with an unrealistic target. More often, they start because the timer is attached to a working calendar that no longer matches the person or group handling the request.

Native JSM calendars are useful when an SLA follows one known service window. When responsibility moves between regional teams, a multi-schedule model gives you a more accurate way to measure actual working time without recreating the same SLA logic for every location.

If your reports contain breaches that are difficult to explain after regional handoffs, it is worth checking whether your SLA timer is measuring work or simply measuring time zones. SLA Time and Report for Jira is worth a closer look when you need one SLA configuration to follow several operational schedules and keep reporting consistent.

How are you currently handling SLA handoffs between regions in Jira: separate calendars, separate configurations, or a shared follow-the-sun model? I’d genuinely like to hear what works in practice.