
See where your team's hours actually went. Slice Jira time data by status, issue type, project, or label to align effort with priorities.

A resolution time report measures the elapsed time between when a Jira issue is created and when it is resolved. It tells you how long stories, bugs, support tickets, or any other issue type sit in your workflow before they close.
The headline metric is usually an average or median, but the real value lives in the breakdown — by status, issue type, priority, assignee, project, sprint, or label. That is where the patterns hide.
A good report is less about declaring "we are fast" or "we are slow" and more about answering the next question: Where is time being lost, and what kind of work is losing it?
It measures the gap between issue creation and issue closure in Jira, then breaks that gap down by whatever dimensions you care about. The core inputs are a start event (typically issue creation), a stop event (a specific closing status transition), and the cohort of issues in scope.
Shared definition of speed. Arguments about velocity collapse into a concrete number anchored in actual closing times.
Early warning on workflow problems. Aging tickets and rising medians surface in the report before they surface as escalations.
Better SLA management. Support and operations teams can spot trends against committed response and resolution windows.
Honest retrospectives. Sprints are easier to debrief when "we were slow" turns into "P2 bugs took 40 percent longer than P3 bugs."
Work through the analysis in this order:
1. Define what "resolved" means in your workflow — the specific status transition that stops the clock. 2. Choose the cohort of issues to study, usually a project, a sprint range, or an issue type. 3. Run the report and look at the distribution, not just the average. A handful of stale tickets can drag the mean badly. 4. Slice by priority, assignee, status, or label to find the segments driving the long tail. 5. Pair findings with workflow analysis — which status is holding the work? Where is it going stale?
The report is the diagnosis. The fix usually lives in queue management, triage practices, or scope.
Timesheet Reports & Gadgets (also referred to as Prime) is a separate Jira app from Timesheets. It is a lightweight reporting layer that extends native Jira time tracking with prebuilt, configurable reports — and the resolution time report is one of them.
Inside Reports & Gadgets, the report breaks elapsed time down by status, so you see how long issues sit in each step of your workflow rather than only the create-to-close number. That status-level view is what turns the report from a vanity metric into a workflow diagnostic.
Because the data comes straight from Jira issues, the numbers reconcile with the work leadership is already tracking. There is no separate analytics stack to maintain, and reports can be surfaced as Jira dashboard gadgets or subscribed to by email so the right stakeholders stay current.
This is distinct from Timesheets, which is the enterprise-class time tracking, billing, and CapEx or OpEx product. Reports & Gadgets is the right fit for teams who want simple, Jira-native reporting on the time and status data they already have.

Timesheets
The #1 time-tracking app for Jira. Timesheets seamlessly integrates with Jira and your existing workflows to help you track time for accounting, CapEx tracking, client billing, compliance, and more.
Start a Free TrialCouldn't find what you need?Go to our documentation
Timesheet Reports & Gadgets and Timesheets are two different Jira apps. The resolution time report lives inside Reports & Gadgets and analyzes Jira status and resolution data – elapsed calendar time, broken down by status. Timesheets is a separate, enterprise-class product focused on logged hours, billing, accounts, and CapEx or OpEx classification. If you want to know how long an issue took to close, you want this report. If you want to know how many billable hours someone logged against it, you want Timesheets.
Resolution time usually measures from issue creation to issue closure. Cycle time typically measures from "in progress" to "done" – it ignores the time an issue waited in the backlog. Lead time often measures from request received to value delivered, which can extend past Jira closure into deployment. Pick whichever metric matches the question you are trying to answer; the trap is using one and pretending it answers all three.
Two common approaches: cap the report window so very old tickets fall out of the cohort, or read the median alongside the average so a few outliers do not move the headline number. The deeper fix is workflow hygiene – aging tickets that nobody intends to do should be closed as won't-fix rather than left to inflate the metric.
Generally not. The moment resolution time becomes a personal scorecard, behavior changes – tickets get closed prematurely, scope gets carved down, and the data quality collapses. It is most useful as a team-level diagnostic, surfaced in retrospectives and used to drive process changes rather than individual reviews.

See where your team's hours actually went. Slice Jira time data by status, issue type, project, or label to align effort with priorities.

Learn how lead time vs cycle time reveals where work slows down, and why tracking both is essential for reliable delivery and strategic forecasting.

Learn to identify bottlenecks, reduce workflow inefficiencies, and boost team productivity with Jira’s time-in-status function and Tempo’s Charts.

Did you know that in Tempo Timesheets for JIRA there’s an easy way to see how much the time spent on issues within an epic?

Discover blockers, assess workloads, and find out how long projects are taking, in a range of eye-catching charts on time in status in Jira.

Knowing the status of work is just as important as knowing when it will finish. See an aggregate of how long work takes for future estimation.

We reveal why you just don't want or need a dedicated Jira time in status app to find bottlenecks. You want something like Custom Charts.

What is strategic drift, and why is a theory from 1988 suddenly urgent again? AI adoption is universal, but why doesn't it show an advantage yet?

A folio can be created for many more initiatives and track financials in Jira other than specific projects