New in Timepiece: SLA Reports for Jira

By Birkan Yildiz on 12/10/2026, 16:13
Last updated on 10/12/26, 4:23 PM

Now Timepiece - Time in Status for Jira has SLA report.

Timepiece - Time in Status for Jira now has an SLA Report. You define a metric, set a target, and run the report. Every work item shows up against that target, met or breached.

Two things make it useful beyond Jira Service Management’s SLAs. First, it runs on any Jira project, not only JSM. And second, it also works on the work items you already have, not just the ones created after you set the metric up.

Most SLAs come down to one of two questions. How long from creation to a status? How long between two statuses? The SLA Report answers both, and some more.

SLA Metrics 2 (2)

 

What Is the SLA Report?

Timepiece’s new SLA Report measures the time between two points in a work item's lifecycle and compares it against a target. Work items appear in rows, SLA metrics appear in columns, and each cell shows the SLA result for that metric. For every metric, the report gives you the SLA status: met, breached, or still in progress. Turn on Show SLA Details and each metric also shows its elapsed time and target. With the SLA report, you can define up to 10 SLA metrics in a single SLA Report.

Why Is This Difficult to Do Otherwise?

Say you promise a first response in four hours and a fix in 3 days. Jira records every status change, so the data is already there. Getting an answer out of it is the hard part.

You can open one work item and read its history. Doing that for 200 of them is not reporting. And for work still in progress, history does not tell you the thing you actually need: which items are still inside their target, and which ones have already passed it.

The SLA Report answers both in one table.

How Do You Define an SLA Metric in Timepiece?

You define a metric with four settings: where it starts, where it stops, where it pauses, and what it runs against.

Start At has three options:

Issue Creation: The metric starts the moment the work item is created.

Statuses: The metric starts when the work item enters any of the statuses you select. If your workflow lets items revisit a status, you choose whether to use the first transition or the last transition.

Date Field: The metric starts on the date in a date field on the work item. This gives each work item its own editable start date.

SLA Metric 3 (3)

 

Stop At has two options:

Statuses: The metric stops when the work item enters any of the statuses you select. If your workflow lets items revisit a status, you choose whether to use the first transition or the last transition.

Date Field: The metric stops on the date in a date field on the work item. This gives each work item its own editable stop date.

Pause On takes statuses only. Select one or more, and the metric stops counting while the work item sits in them and resumes when it leaves. This is how you keep "Waiting for Customer" out of a response time SLA.

What Target Types Can You Use?

There are 4, and the last 3 are what make this useful beyond basic service desk tracking.

Duration Based: A fixed value applied to every work item in the report. Set to 2 days, and every item runs against 2 days. This is close to how Jira Service Management SLAs work.

Number Field Based: A per work item numeric target. Pick a number field and a unit, and each item runs against whatever value that field holds on that item.

Date Field Based: A per work item date target. Pick a date field, and each item runs against its own target date.

Date Based: One fixed date and time for every item in the report. Set October 1, 2026 00:00 and every item runs against that moment. In practice each item ends up with a different amount of time, depending on when it was created or transitioned.

The two field based options set the target per work item instead of per report. Whatever drives the target, such as priority, customer tier, or a date agreed with a stakeholder, you put it in a field and the report reads it.

sla-details-view-menu (2)

 

How Do You Read the Results?

Each metric shows two things at once: the state of the metric, and the result against the target.

The state is where the metric is in its lifecycle.

  • Not Started. The work item has not reached the starting point. No value is shown.
  • Running. The metric started and is still counting up to the present moment.
  • Paused. The metric started and has not stopped, but the item is sitting in one of your pause statuses, so counting is on hold.
  • Completed. The metric reached its stop point.

The result is where that metric stands against its target. The icon next to the value tells you both.

Icon

State

Against target

Gray clock gray clock yeni

Running

Within target, still in progress

Red clock Red Clock Icon Yeni

Running

Already breached, still counting

Pause icon Pause Icon Yeni

Paused

Counting on hold

Green check Green Checj Yeni

Completed

Met

Red cross Red cross yeni

Completed

Breached

The pairing that matters most is the red clock. The work is not finished, and the target is already gone, so the only thing still open is how far overdue it ends up. A gray clock is the opposite case: still running, still inside the target, and still able to finish as met.

By default, each metric shows one SLA column. Turn on Show SLA Details in the View Format panel, and you get two more columns per metric, for Elapsed and Target.

Can You See SLA Aging?

Yes. The Aging of SLA Targets report groups work items by how far they are from their SLA target. You set the bucket size by entering a period and selecting its unit.

Aging Metric (1)

 

Work items land in one of these groups:

Not Started: The metric has not reached its starting point.

Within Target: Completed inside the target.

Interval Buckets: Grouped by how far past the target they went, in the interval you set.

Ongoing (Within Target): Still running and still inside the target.

Ongoing (Breached): Still running and already past the target.

Instead of a flat list, you get a distribution. It shows whether your breaches are a few stragglers or a widening pattern, and how much of the overdue work is still open.

Who Should Use SLA Reports in Jira?

Service and operations teams get response, resolution, and handoff times measured against the targets they committed to. The report shows whether requests finished inside the agreed time and where the target was exceeded.

Project and program managers get an answer to "what is the status, and why is it late" that is specific to a stage rather than the whole item.

Scrum Masters get retrospective input that is not anecdotal. If Code Review has a target and keeps finishing red, that is a process finding, not a feeling.

Engineering leads get a measure of the system rather than the people. An SLA on a workflow step describes how long a stage takes, which is a different conversation from how fast an individual works.

Jira admins get SLA reporting without adding another tool to the instance, since this runs inside an app they already have.

To use SLA Report, open the Timepiece reporting page, select your project, and switch the report type to SLA Report. The SLA Metrics button appears once that report type is selected. Define one metric, give it a target, and run it.

Step-by-step instructions for every option are in the Timepiece documentation.

If you want to see it against your own workflows, start a 30-day free trial on the Atlassian Marketplace. Alternatively, you can book a live demo and our experts will walk through your setup with you.

Topics: Timepiece