Time in Status Report and Status Transition Report
- 1 Overview
- 1.1 Where to find it
- 1.2 Data Setup
- 1.2.1 1. Get data
- 1.2.2 2. Set data
- 1.3 Report Output
- 1.4 Use Cases
- 1.5 Tips & Best Practices
- 1.6 Other useful measures to customise the report
Overview
The Time in Status report helps teams monitor how long issues remain in each status across their lifecycle. This is especially useful for identifying bottlenecks, process inefficiencies, and understanding flow durations in ITSM or Agile environments.
Where to find it
Navigate to Create report → ITSM reports → Select “Time in Status”.
📌 You can also find it under Templates or by using the search bar.
Data Setup
After selecting the report, define your dataset:
1. Get data
Set the scope by choosing a Jira project or filter. Optionally apply conditions (e.g., issue type contains "Bug").
2. Set data
Configure how your data will be grouped and calculated, for example:
Setting | Value Example |
---|---|
Group rows by | Project → Issue Type → Issue |
Group columns by | Changelog Status |
Calculate values | Sum of Time in Status |
You can add or remove fields as needed using the Add field button.
Report Output
Each row in the table represents a Jira issue or issue group (e.g., project or issue type), and each column shows the total time spent in each status.
The following values are calculated:
Time spent in To Do, In Progress, Done, etc.
The Total column aggregates all status durations.
Use Cases
Identify process delays (e.g., long time in “In Progress”).
Measure issue aging by status.
Monitor team responsiveness and completion trends.
Audit compliance with SLA targets for time spent in statuses.
Tips & Best Practices
Combine with filters like issue type, labels, or changelog assignee for focused insights.
Save the report and configure recurring views to track improvements.
Use conditional formatting to highlight rows, columns, or specific values
Export to Excel or PDF to share results with stakeholders.
Other useful measures to customise the report
Note: Combine these measures with “Changelog status“ or “Changelog assignee“ fields to get the data for all historical statuses and assignees.
👤 Time in Assignee
Description:
Calculates the total time an issue was assigned to each user throughout its lifecycle. This is based on the issue’s assignee change history (changelog).
Example Use Case:
Understand workload distribution by measuring how long each team member held issues.
🔁 Count of Status Occurrences
Description:
Counts how many times an issue entered each status. Useful for identifying frequent ping-pong between statuses or reopened tickets.
Example Use Case:
Find issues that were reopened multiple times or bounced between “In Review” and “In Progress”.
📆 First/Last Entered or Exited Status
Description:
Tracks the first or last timestamp when an issue entered or exited a specific status. Useful for building custom SLA checks or understanding lifecycle timing.
Variants:
First Entered Status
Last Entered Status
First Exited Status
Last Exited Status
Example Use Case:
Find when a ticket first entered “Waiting for Support” or when it last exited “Backlog”.
🕒 Time in Status 24/5
Description:
Calculates time spent in status, assuming 24 hours per day, 5 working days per week (Monday to Friday). Ignores weekends and outside working days, making it more business-context accurate.
Example Use Case:
Measure resolution time while excluding weekends from the calculation for SLA compliance.