SLA Time and Report in Action

SLA Configuration

SLA Time and Report helps Jira teams configure SLA rules that match how their work actually moves through the workflow.

Common configuration options include 👉

• Start conditions to define when the SLA timer begins.

• Pause conditions to stop counting time during waiting states, such as “Waiting for Customer” or “Waiting for Vendor.”

• Stop conditions to complete the SLA when the work item reaches the final status.

• Reset rules to restart the SLA when a specific condition is met, for example, when an issue is reopened.

• Multi-cycle logic for work items that move between the same statuses more than once.

• SLA goals by context, such as priority, severity, request type, service, team, or custom fields.

• Work schedules and calendars to calculate SLA time based on business hours.

• Pre-breach notifications to warn teams before an SLA is exceeded.

• Automated actions when SLA time is close to the limit or already breached.

• The SLA timer starts when the selected condition is met.

• The timer pauses when the issue enters a waiting status.

• The timer resumes when work continues.

• The SLA can reset if the issue is reopened or another reset condition is triggered.

• The active SLA appears directly on the work item.

• Teams can see remaining or elapsed SLA time.

• Pre-breach alerts notify responsible users before the deadline is missed.

• Automated actions can be triggered when the SLA is at risk or exceeded.

• SLA results are stored for reports, charts, exports, and dashboards

What happens after SLA starts

Once a Jira work item matches the configured SLA conditions, SLA Time and Report begin tracking time automatically.

Flow Overview: Service Request SLA Tracking

A customer or internal user creates a service request in Jira.

Upon creation or workflow transition:

1. A Jira work item enters the support workflow.

2. SLA Time and Report checks whether the issue matches the configured SLA conditions.

3. The SLA timer starts based on the selected rule, for example when the issue is created or moved to “In Progress.”

4. The correct SLA goal is applied based on priority, request type, service, customer, or another field.

5. The timer pauses if the issue moves to a waiting status.

6. The timer resumes when the team can continue working.

7. A pre-breach notification is sent when the SLA approaches the limit.

8. The SLA stops when the request reaches the final status.

Result

• Teams see SLA time directly on the work item.

• High-risk requests are easier to detect before they breach.

• Waiting time is separated from active work time.

• Managers can review SLA performance by project, priority, assignee, service, or other criteria.

• SLA results are available in reports and dashboard gadgets.

Flow Overview: Cross-Team OLA and Handoff Tracking

A support request requires help from another team, for example Development, QA, Security, Legal, or Finance.

During the workflow:

1. The original work item moves from the first team to another responsible team.

2. An internal SLA or OLA starts for the handoff stage.

3. The timer tracks how long the issue stays with the responsible team.

4. If the issue waits on a customer, vendor, or approval, the SLA can pause.

5. If the issue returns for rework, multi-cycle logic can track repeated time cycles.

6. If the handoff takes too long, alerts or automated actions can notify the right people.

7. Reports show where delays happen across the workflow.

Result

• Internal ownership becomes clearer.

• Teams can see which handoff stage causes delays.

• OLAs become measurable, not just agreed verbally.

• Managers can identify repeated bottlenecks between teams.

• Support, development, QA, and operations can work from the same SLA data.

Flow Overview: Global Team SLA Tracking

A distributed team works across different regions, time zones, or business schedules.

With SLA Time and Report:

1. A work item is assigned to a team member or group.

2. The SLA timer follows the configured work schedule.

3. Non-working hours, weekends, or holidays are not counted if the calendar is configured this way.

4. For advanced multi-calendar scenarios, SLA calculation can reflect the relevant assignee’s working schedule.

5. Teams avoid false breaches caused by off-hours or regional differences.

6. Managers get more accurate SLA results across locations.

Result

• SLA time reflects real working hours.

• Global teams are measured more fairly.

• Regional schedules are easier to manage.

• SLA reporting becomes more accurate for distributed support, ITSM, engineering, and operations teams.

Flow Overview: SLA Reporting and Dashboard Monitoring

After SLA data is collected, teams can use reports and dashboards to review performance.

In practice:

1. Team leads open the SLA Grid to review active and completed SLA results.

2. Managers use SLA chart reports to compare met and exceeded goals.

3. Teams analyze SLA performance by priority, assignee, service, organization, project, or custom field.

4. SLA charts can be added to Jira Dashboards as gadgets.

5. Reports can be exported for audits, service reviews, QBRs, or leadership updates.

6. Repeated breaches can be used as input for workflow improvements.

Result

• SLA performance is visible without manual reporting.

• Teams can detect repeated problem areas.

• Managers can prepare stakeholder reports faster.

• Jira becomes a single place for SLA tracking, monitoring, and performance analysis.

Example Scenario: High-Priority Incident

A high-priority incident is created in Jira Service Management.

The team has configured:

• Time to First Response for the first customer reply.

• Time to Resolution for full incident completion.

• A business-hours calendar.

• Pause logic for “Waiting for Customer.”

• Pre-breach alerts before the SLA deadline.

• SLA reports for weekly review.

During the process:

1. The issue is created with High priority.

2. SLA Time and Report applies the High-priority goal.

3. The support team sees the countdown in the work item.

4. If the issue is close to breach, the team receives an alert.

5. If the issue waits for the customer, the SLA pauses.

6. When the issue is resolved, the SLA stops.

7. The result appears in SLA reports and dashboard charts.

Result

• The team knows which incidents need attention first.

• Managers can see whether high-priority issues are handled on time.

• Breaches are easier to prevent, not only report after they happen.

• SLA data can be used for service reviews and process improvement.

What teams can achieve with SLA Time and Report