SLA goal types in Jira: how to choose between Time Limit and Negotiated Date 🤔

[#1]

Two support teams, same Jira setup, both tracking SLA compliance. One team resolves tickets against a fixed 8-hour window. The other works with clients who each have a project deadline written into their contract – different dates, different commitments, same queue. If both teams are using a "Time to Resolution" SLA with a single time target, one of them is measuring the wrong thing entirely.

The choice of SLA type isn't a technical detail you sort out once and forget. It shapes what your SLA data actually means, and whether it reflects real accountability or just timer activity. In SLA Time and Report for Jira, this choice usually starts with one practical question:

Are you tracking a fixed amount of working time, or are you tracking completion before a specific date?

🧩 What SLA types exist in SLA Time and Report

SLA Time and Report for Jira supports four SLA types, each suited to a different operational model:

Time limit — Single project: fixed duration target (e.g., 4h, 1d) measured from start to stop condition. The standard choice for most support and service desk setups.

Time limit — Multiple projects: same logic, but one configuration applies across several Jira projects at once — useful when teams share the same SLA policy and you want centralized management.

Negotiated date: the target is a specific date pulled from an issue field — Due Date, Target Date, or any custom date field. Each issue has its own deadline; the SLA tracks whether it was resolved before or after that date.

Multiple-scheduler (Advanced plan): SLA time is calculated against the work schedule of the current assignee. Reassign to someone in a different region, and the SLA switches to their calendar automatically.

The most common decision point is between the first and third types. Let's look at what actually separates them in practice.

⏱️ Time limit: when the same clock applies to everyone

The time limit type makes sense when your SLA commitment is consistent across all tickets of a given category. You've agreed to respond within 1 hour to critical issues, or to resolve standard requests within 3 business days. The target doesn't change based on who submitted the ticket or when.

In SLA Time and Report, you set up a time limit SLA by defining start and stop conditions, selecting a working calendar, and specifying the goal duration. The Context by feature lets you apply different time targets based on issue fields, for example, 1h for Critical priority, 4h for High, 8h for Medium. Each goal runs against the same working calendar, but the threshold adapts to the issue context.

By default, 1 day equals 8 working hours, but you can adjust this in the work schedule settings.

When to use it: internal IT helpdesks, customer support with tiered SLAs by priority, service desks where all customers have the same contractual terms.

What doesn't work here: if your tickets have individually negotiated deadlines, a fixed time limit will either be too generous for some and impossible for others. The SLA number will average out, but the individual accountability disappears.

📅 Negotiated date: when every deadline is different

The negotiated date type treats the SLA target as data stored on the issue, not as a configuration value. You select a date or date-time field – Due Date, Target Date, or any custom date field you've created, and the app measures whether the issue was closed before or after that specific date.

This means the SLA logic is: start condition met → timer runs against the date in the selected field → stop condition met → SLA result is met or exceeded.

Important constraints to know before configuring this type: pause conditions, multi-cycle options, and SLA reset are not available for negotiated date SLAs. The reason is structural – the SLA is anchored to a fixed deadline, not accumulated time. Pausing a timer against a specific date doesn't have a clear meaning in the same way it does for a duration-based SLA.

Automated actions still work: when the negotiated deadline is missed, the app can change assignee, change priority, change status, or send a Slack notification. Non-working hours are excluded from the calculation based on the configured work schedule, so if the Due Date is set to 5:00 PM and working hours end at 6:00 PM, only that window counts.

When to use it: project-based work with committed delivery dates, legal or compliance tasks with regulatory deadlines, client onboarding or implementation projects where each engagement has its own timeline.

One practical prerequisite: the selected date field must be consistently populated in your issues. If Due Date is blank on half your tickets, the SLA won't start for those issues. Before switching to this type, run a quick audit: pull all open issues in the relevant project and filter by due is EMPTY to see how many would fall outside SLA tracking.

project = "YOUR_PROJECT" AND due is EMPTY AND statusCategory != Done

If the number is high, solve the data quality problem first. Automating a Jira rule to require Due Date on issue creation is worth doing before the SLA configuration, not after.

The short difference Time Limit vs Negotiated Date

The short version:

Time limit = "How much time can this take?" — used when every issue follows a fixed target: first response within 2 hours, resolution within 8 hours, bug triage within 7 hours.

Negotiated date = "Was this done before the agreed deadline?" — used when each issue has its own date: Due Date = May 15, Target Date = next Friday, a custom "Commitment date" field.

The table below maps common use cases to the right type:

Context	Example	SLA type
Priority-based support	Critical – 1h / High – 4h / Medium – 1d	Time limit
Work item type	Bug triage – 8h / Incident – 4h	Time limit
Severity-based ITSM	Sev 1 – 30 min / Sev 2 – 2h	Time limit
Customer tier	Enterprise – 1h / Standard – 8h	Time limit
Client delivery commitment	Due Date per contract	Negotiated date
Project/implementation tasks	Target Date per milestone	Negotiated date
Legal or compliance deadlines	Regulatory date field	Negotiated date
Release-related work	Must complete before release date	Negotiated date

🔀 🌍 What about global teams and different schedules?

Sometimes the issue is not only the SLA type. It is the calendar behind it.

For example, a ticket starts with a support agent in Canada and later moves to an engineer in Poland. If one shared calendar is used for everyone, the SLA can look unfair because time may be counted outside the active assignee’s real working hours.

For this case, SLA Time and Report also has a Multiple-scheduler SLA type. It calculates SLA time based on the work schedule assigned to the current assignee or group. When the assignee changes, the SLA switches to the new assignee’s calendar. If the assignee is not linked to a work schedule, the SLA does not start.

This is not a replacement for choosing between Time limit and Negotiated date. It is another layer for teams that need SLA tracking across different calendars, regions, or working hours.

A simple rule for Jira admins

When choosing an SLA goal type, do not start from the app settings. Start from the promise. Ask:

1. Is the promise the same for a group of issues? Use Time limit based SLA.
2. Is the promise different for every issue and stored in a date field? Use Negotiated date SLA.
3. Do several projects follow the same rule? Use Time limit based Multiple projects.
4. Do teams work across different schedules or regions? Check whether Multiple-scheduler SLA is needed.

This small decision can prevent a lot of reporting noise later.

---

Final thoughts

The SLA type you choose defines the question your compliance data is actually answering. A time limit SLA answers: "did we meet our standard target for this category of work?" A negotiated date SLA answers: "did we deliver against the specific commitment we made to this stakeholder?"

Neither is a default. If your team is setting up SLAs in Jira for the first time, starting with a time limit type for standard response and resolution metrics is usually the right call. If you're managing project-based delivery or client-specific commitments, building a negotiated date SLA alongside it gives you a second layer of accountability that the time limit type simply can't provide.

Worth revisiting your current configuration if you've been using only one type across all your work,  there may be a category of tickets where the clock you're measuring against doesn't match the commitment you actually made.

Happy to dig into specific configuration scenarios in the comments, particularly around the negotiated date type and how teams handle the data quality dependency.