Time Between Statuses Report: How to Track Workflow Delays and Bottlenecks

[#1]

If your team needs to understand not only how long work takes, but also where time is spent between statuses, a Time Between Statuses report can give you a much clearer view of workflow delays and bottlenecks.

Jira stores issue history and status changes, but turning that data into a practical time report is not always simple. That is where apps like Time Metrics Tracker by SaaSJet can help teams create custom time metrics, measure time between selected Jira statuses, apply working calendars, exclude non-working periods, set limits, and analyze workflow delays without exporting everything to spreadsheets.

Why time between statuses matters

A final resolution time, cycle time, or lead time number can show that something is slow.

But it does not always explain why.

For example, two issues may both take 10 days to complete:

• one issue spent most of the time in active development;
• another issue spent only one day in development and nine days waiting for approval.

The total time is the same, but the problem is different.

In the first case, the team may need to review task complexity or engineering capacity.
In the second case, the team may need to improve the approval process.

That is why tracking time between Jira statuses is useful. It helps teams separate:

• active work time;
• waiting time;
• review time;
• approval time;
• blocked time;
• queue time;
• customer response delays;
• vendor or dependency delays;
• time spent in each workflow stage.

What is a Jira Time Between Statuses report?

A Jira Time Between Statuses report shows how much time issues spend between selected workflow points.

Depending on your workflow, this can mean tracking time:

• from To Do to In Progress;
• from In Progress to Done;
• from Ready for Review to Approved;
• from Waiting for Customer to Resolved;
• from Request Submitted to Approved;
• from Blocked to Unblocked;
• from QA to Release.

The goal is to understand where work gets stuck and what slows the process down.

For many teams, this report becomes a practical way to answer questions like:

• How long do issues wait before work starts?
• Which status causes the biggest delay?
• Are approvals slowing down delivery?
• Is QA becoming a bottleneck?
• Are support tickets delayed because of customer waiting time?
• Which issues exceeded expected time limits?
• Are delays caused by a few outliers or by a wider workflow problem?

Key Jira time metrics teams often track

Before creating a Time Between Statuses report, it helps to understand the most common Jira time metrics and how they differ.

Cycle Time

Cycle Time measures how long it takes to complete work after it has started.

For example:

In Progress → Done

This metric is especially useful for Agile, Kanban, and delivery teams because it focuses on execution time. It helps teams understand how efficiently work moves once someone starts working on it.

If Cycle Time increases, the next step is to break it down by statuses and see where the delay happens: development, review, QA, blocked, or release.

Lead Time

Lead Time measures the total time from request creation to completion.

For example:

Created → Done

Lead Time is useful for understanding the full customer or stakeholder waiting time. It includes both queue time before work starts and the time spent actively working on the issue.

This metric is helpful for project managers, product teams, service teams, and operations teams that need to understand how long it takes to deliver a request from start to finish.

Time to Resolution

Time to Resolution measures how long it takes to fully resolve or close an issue.

This is especially important for support and IT service teams because it is often connected to SLA performance and service quality.

However, Time to Resolution alone may not show why a ticket took too long. That is why it is useful to combine it with Time in Status or custom metrics, such as time spent in Waiting for Customer, Escalated, or Blocked.

Time to First Response

Time to First Response measures how long it takes from issue creation to the first reply or acknowledgment.

This metric is important for support, ITSM, and customer-facing teams because the first response often affects customer satisfaction, even if the final resolution takes longer.

A long Time to First Response may indicate problems with triage, ticket assignment, staffing, or notification rules.

Custom time metrics

Every team’s workflow is different, so predefined metrics are not always enough.

Custom metrics allow teams to measure the exact part of the workflow that matters to them.

For example:

• Review Time: Ready for Review → Approved
• Approval Time: Submitted → Approved
• Blocked Time: Blocked → Unblocked
• Vendor Waiting Time: Sent to Vendor → Vendor Response Received
• QA Time: Ready for QA → QA Passed
• Deployment Time: Ready for Release → Released
• Customer Waiting Time: Waiting for Customer → Customer Responded

This is where Time Metrics Tracker becomes especially useful. Teams can create metrics that match their actual Jira workflow instead of relying only on general reports.

Common workflow delays this report can reveal

A Time Between Statuses report is especially useful when your Jira workflow includes waiting stages, approvals, handoffs, or dependencies.

Engineering and Agile teams

Engineering teams can track how much time issues spend in:

• development;
• code review;
• QA;
• blocked;
• ready for release;
• deployment.

For example, if Cycle Time increases, the report can show whether the delay is caused by development itself or by waiting in review, QA, or release.

This helps Agile teams bring concrete data into retrospectives instead of relying on assumptions.

Support and IT service teams

Support and IT teams can measure:

• Time to First Response;
• Time to Resolution;
• waiting for customer;
• escalation time;
• blocked support stages;
• SLA-related delays.

This helps teams understand whether delays are caused by internal handling time, customer waiting time, escalation queues, or unresolved blockers.

For example, a ticket may look slow overall, but the team may discover that most of the delay happened while waiting for customer information.

Procurement and approval workflows

Procurement teams can use Jira to manage requests from submission to approval, vendor communication, purchase, and completion.

A Time Between Statuses report can show:

• how long requests wait for initial review;
• how long approvals take;
• how much time is spent waiting for vendor response;
• which requests are blocked by missing information;
• where procurement delays happen most often.

This is important because procurement delays are not always caused by the same stage. Sometimes the bottleneck is internal approval. Sometimes it is vendor response time. Sometimes the request is waiting because required details are missing.

Operations teams

Operations teams can track time between intake, assignment, execution, validation, and completion.

This helps them understand whether work is delayed before it starts, during execution, during review, or at the final validation stage.

How to build a Time Between Statuses report in Jira

Before you start analyzing workflow delays, define what exactly you want to measure.

A Time Between Statuses report becomes useful only when the metric reflects a real workflow question, for example:

• How long do issues wait before work starts?
• How much time do tasks spend in review?
• How long does approval take?
• How much time is spent in Blocked or Waiting for Customer?
• Which stage adds the most delay to the overall process?

Once the question is clear, create a time metric that matches this part of your Jira workflow.

Step 1: Define and create your time metric

In Time Metrics Tracker, a time metric defines which part of the workflow should be calculated.

For example, you can create metrics such as:

• Queue Time: To Do → In Progress
• Review Time: Ready for Review → Approved
• Approval Time: Submitted → Approved
• Blocked Time: Blocked → Unblocked
• QA Time: Ready for QA → QA Passed
• Resolution Time: Created → Resolved
• Cycle Time: In Progress → Done

Go to the Time Metrics Tracker app, open Configuration, and click + Time metrics. Then select the required project, choose the work schedule that should be used for calculations, and define the status transitions for the metric. 

After that, define the calculation conditions by selecting the needed status transitions: from which status the timer should start and to which status it should calculate time. You can also choose statuses where the calculation should pause if they should not be counted as active workflow time.

This is helpful when you need to separate active work from waiting time. For example, a support team may calculate Resolution Time but pause or exclude time spent in Waiting for Customer. A procurement team may separate internal Approval Time from Vendor Waiting Time.

Step 2: Set warning and critical limits

After you define the metric logic, set Warning and Critical time limits.

These limits help make the report easier to read because work items are visually highlighted when they exceed the expected time:

• Warning time limit — yellow
• Critical time limit — red

Step 3: Display the metric on the grid report

Once the metric is created, go back to the report and select the time metrics you want to display on the grid.

Click Time metric and choose the checkboxes for the metrics you want to include in the report.

For example, you can display several metrics together:

• Cycle Time
• Review Time
• Blocked Time
• Approval Time
• Time to Resolution

This helps you compare different parts of the workflow in one table and see whether delays are caused by active work, review, approval, blocked stages, or waiting time.

Step 4: Filter the report by your workflow scope

To make the report more focused, use filters to narrow down the data.

For example, you can filter the report by:

• Board
• Type
• Status
• Assignee
• Label
• Sprint

This is useful when you do not want to analyze the entire project at once.

For example, you can check only bugs from a specific sprint, tasks assigned to a specific team member, issues with a certain label, or work items from a selected board.

This makes the report more practical for team reviews, retrospectives, support analysis, procurement tracking, or operational reporting.

Step 5: Sort metrics to find the biggest delays

After the metrics are displayed on the grid, sort the report by metric value.

You can sort metric columns in descending order to see which issues took the longest time, or in ascending order to see the fastest-moving work items.

This is one of the quickest ways to find bottlenecks.

For example:

• sort by Review Time to find issues stuck in review the longest;
• sort by Approval Time to see which requests waited too long for approval;
• sort by Blocked Time to identify items affected by dependencies;
• sort by Resolution Time to investigate the slowest tickets.

Instead of checking issues manually, you can immediately focus on the work items with the highest delay.

Step 6: Check the average value

The grid report also helps you understand the average value for a selected time metric.

This is useful when you want to evaluate the overall workflow performance, not only individual outliers.

For example, if the average Review Time is increasing, it may indicate that review capacity is becoming a process bottleneck. If only one issue has a high value, it may be an exception. But if many issues are above the average or the average itself is growing, the team may need to review the workflow stage more closely.

Average values are especially useful when comparing:

• different sprints;
• different issue types;
• different teams;
• different workflows;
• different time periods.

Step 7: Save or export the report

If you use the same filters and metrics regularly, save the report view.

This helps you avoid rebuilding the same report every time. For example, you can save views for:

• sprint review;
• support resolution analysis;
• procurement approvals;
• blocked issues monitoring;
• review bottleneck tracking;
• monthly workflow health review.

You can also export the report when you need to share the data outside Jira or continue analysis in Excel or Google Sheets.

This is useful for stakeholder reporting, audits, performance reviews, or deeper analysis across teams.

Step 8: Add the report to a Jira dashboard

For ongoing monitoring, you can also display time metrics on a Jira dashboard using the Agile Metrics Dashboard Gadget.

This is useful when teams want to track workflow delays without opening the full report every time.

The dashboard gadget can show selected time metrics and can be configured by project, issue type, status, assignee, sprint, label, date range, and other report settings.

For a more complete workflow health view, you can combine the grid-based Agile Metrics gadget with other Time Metrics Tracker dashboard gadgets, such as:

• Trend Gadget — to see whether the metric is improving or getting worse over time;
• Status Contribution Chart Gadget — to understand which statuses contribute most to the total time;
• WIP Run Chart Gadget — to monitor work-in-progress pressure;
• Scatter Plot Gadget — to spot delayed issues and outliers.

Together, these views help teams move from a static report to a more connected workflow health dashboard.

Final thoughts

A Jira Time Between Statuses report is useful because it answers a practical question:

Where does work actually wait?

Total Cycle Time, Lead Time, or Resolution Time can show that something is taking too long. But time between statuses helps explain where the delay happens and what kind of action may improve the process.

For Agile teams, it can reveal review, QA, or release bottlenecks.
For support teams, it can separate active work from customer waiting time.
For IT teams, it can support SLA-related analysis.
For procurement and operations teams, it can show approval, validation, and vendor-related delays.

If your Jira workflow has multiple stages, approvals, waiting statuses, or handoffs between teams, tracking time between statuses can help you move from general reporting to practical workflow improvement.

And if you want to build these reports directly in Jira, Time Metrics Tracker can help you create custom time metrics, apply working calendars, exclude selected statuses, set limits, and analyze workflow delays with reports, Flow Insights, and dashboard gadgets.