How Time in Status Calculates Report Values – FAQ
Time in Status uses Jira issue history, calendars, and time formats to calculate how long work items stay in each status, for each assignee, and across your workflow. This FAQ explains how the app calculates values across different reports, how work schedules and time zones affect results, and how to avoid common mistakes when interpreting metrics.
1. How does the Time in Status app generally calculate time in reports?
Time in Status reads each work item’s status history and sums up the durations between status changes. When an issue enters a status, a timer starts; when it leaves that status, the timer stops. These intervals are added together to get total time in each status.
The same base logic is reused across reports (Time in Status, Average Time, Assignee Time, Time in Status per Date, etc.), but each report aggregates the data differently (by status, assignee, date, or status group).
2. What are work schedules, and how do they affect report calculations?
Work schedules (work calendars) define working days, working hours, breaks, holidays, and time zone for your team. Time in Status uses the selected calendar to convert raw elapsed time into business time:
If a calendar day is 24 hours and 1 business day = 8 hours, then:
8 elapsed hours = 1 business day
24 elapsed hours = 3 business days
Business formats (like Business Decimal Days or Business DaysHoursMinutes) use your calendar’s working hours instead of 24h days.
This means the same raw duration can be shown as different values depending on whether you view it as calendar days or business days, but the underlying hours are the same.
3. What is the difference between 0 and “–” in the Time in Status table view?
In Time in Status tables:
“–” (dash) means the work item was never in that status at all. There is no recorded time.
0(zero) means the work item was in that status, but the time was so small that it rounded down to zero in the selected time format. For example, a very short transition (less than the rounding threshold) can appear as 0.
So:
“–” = status not used
0 = status used, but time rounded down in the current format.
4. How do time formats (Minutes, Hours, Decimal Days, Business formats, etc.) work?
The Format option controls how durations are displayed, not how they are internally stored. Key behaviors:
Minutes / HoursMinutes / Hours:Minutes / DaysHoursMinutesSeconds – show durations in standard calendar units.
Decimal Hours / Decimal Days / Decimal Weeks – convert the duration into a single decimal number; very small values (< ~30 seconds) may be rounded to
0.00, slightly larger ones to0.01.Business Decimal Days / Business Decimal Weeks / Business DaysHoursMinutes – use your work calendar (e.g., 1 business day = 8h). The same raw duration will appear as more business days if your working day is shorter.
If you see unexpected values, check:
Which format is selected.
Whether you’re using calendar-based or business-based formats.
5. How do timezones influence Time in Status calculations and outputs?
Time in Status uses two timezone sources:
Calendar timezone – used to calculate durations in statuses and transitions (Time in Status, Time in Status per Date, Assignee Time). If a status change happens at 5 PM in one timezone, it might cross to the next day in another, which affects how durations map to dates.
User’s Jira timezone – used to display date-time fields like Created, Updated, Resolved, Start Date, Due Date, and also Status Entrance Date values.
As a result:
Time spent in statuses is calculated according to the calendar’s timezone.
Date/time columns in Jira are shown according to the user’s Jira timezone.
6. What are “Work items period” and “Report period” and why do they both matter?
Time in Status uses two separate date ranges:
Work items period – selects the list of issues included in the report.
Filter by Created, Updated, or Resolved date.
Example: “Issues resolved last week.”
Report period – defines the time window for calculations for those issues.
Example: “For those issues, only calculate time spent during last week.”
Rules and tips:
If you don’t set Report period, the app uses Any date (full history).
Report period cannot be earlier than Work items period.
If you set future dates in Report period, you’ll get no data.
If both Sprint and date periods are set, the scope must still be consistent with the Sprint.
Correctly setting both periods is crucial for accurate, performant reports and to avoid “broken” or empty gadgets.
7. How is the Time in Status report calculated?
The Time in Status report sums the total time a work item has spent in each workflow status:
If a task is in “To Do” for 2 hours, later returns to “To Do” for another 2 hours, Time in Status shows 4 hours in “To Do”.
This logic applies to all statuses and over the entire period defined by Work items period + Report period + calendar.
If you use Status Groups (e.g., “Cycle Time”, “QA Time”), Time in Status also calculates the sum across all statuses in that group.
8. How does the Time in Status per Date report work?
The Time in Status per Date report breaks the time in status down by time interval:
You select an interval: Daily, Weekly, Monthly, Quarterly.
Time in Status calculates how much time the selected tasks spent in each status within each interval.
Status Groups in this report work the same way: they sum time across all statuses in the group per interval.
This report is ideal for observing trends over time (e.g., “How did time in ‘Blocked’ change week by week?”).
9. How is the Average Time report calculated (including Status Groups)?
The Average Time report shows the average time in status over a selected period and scope:
Count how many tasks have been or are in a given status during the period.
Sum the total time spent in that status for those tasks.
Compute:
Average Time in Status = Total Time in Status ÷ Number of Tasks
For Status Groups in Average Time:
The app sums all values for the statuses inside the group and divides by the number of records, excluding zero values (so tasks that never touched that group don’t skew the result).
Intervals (Daily, Weekly, Monthly, Quarterly) allow you to see how the average changes over time.
10. How is the Assignee Time report calculated, and how do User Groups work?
The Assignee Time report measures how long a work item was assigned to specific people:
Each assignee column shows how long the work item was assigned to that person within the chosen Report period, adjusted by calendar and format.
The Total column shows the combined assignee time for all users who worked on that item.
User Groups (in Columns Manager on Assignee Time report):
You define a group (e.g., “L1 Support”, “Backend Team”) and add Jira users to it.
The report then aggregates their assignee times into a single group column, so you see time per team or function rather than per individual.
After creating or editing groups, you must Save in Column Manager (and re-save any affected presets) for changes to apply.
11. How is the Status Count report calculated?
The Status Count report shows how many times each work item has been in every status:
Each cell counts the number of entries into that status.
If an issue moves into “In Progress” three separate times, Status Count for “In Progress” will be 3.
This is useful for identifying rework and loops (e.g., issues bouncing between “In Progress” and “Testing”).
12. How is the Transition Count report calculated?
The Transition Count report counts the number of transitions between specific statuses:
Column names indicate the status pair (e.g., “In Progress → In Review”).
Each value shows how many times an issue moved along that transition during the selected period.
This reveals repetitive back-and-forth flows and handoff problems across the workflow.
13. How is the Status Entrance Date report calculated?
The Status Entrance Date report shows the first date and time when a work item entered a specific status:
Time in Status reads the status change history and records the first entrance into each status.
These dates are displayed according to the user’s Jira timezone.
This report is helpful when you need to know when issues first hit the “In Progress”, “In Review”, “Ready for QA”, etc. states, for auditing or SLA checks.
14. How do Status Groups work, and how do they help calculate Cycle and Lead Time?
Status Groups let you sum time across multiple statuses into one column:
You create a group in Status Groups (within Columns Manager):
Name the group (e.g., “Cycle Time”, “QA Phase”, “Lead Time”).
Select the statuses to include (e.g., In Progress + In Review + Testing).
Time in Status then calculates one column that sums time from all those statuses, in any of these reports:
Time in Status
Average Time
Status Count
Time in Status per Date
This is how you calculate Cycle Time and Lead Time aligned with your own process, not just raw status-level metrics.
15. How are Time in Status custom fields calculated and updated?
Time in Status custom fields calculates time per work item and shows it directly on boards and issue views:
They reflect only the time spent in the current status for each task.
If an issue returns to the same status multiple times, the custom field uses accumulated time:
Total time in a status = sum of all entries into that status for the issue.
Custom fields are updated every hour, so values may lag slightly behind real-time but stay performant.
The time in the rightmost status column is not calculated to avoid issues for Kanban teams (so closed items don’t “disappear” from boards due to constant updates).
Each custom field is tied to a specific work schedule, and the linked calendar cannot be deleted (though it can be edited).
16. How do dashboard gadgets calculate and display Time in Status data (including trim/time reporting option)?
The Time in Status Gadget on Jira dashboards uses the same core logic as the app, with a gadget-specific configuration:
You choose:
Report type (Time in Status, Assignee Time, Average Time, Status Entrance Date, Time in Status per Date, Status Count, Transition Count).
Filters (Assignee, Filter, Label, Project, Reporter, Sprint, etc.).
Work items period & Report period for date ranges.
Calendar (custom or 24/7) and Time format.
View: Table (Work Item List) or Graph (Pie, Bar, Area, Sunburst).
Time reporting (trim) option in the gadget:
Let's you limit the calculation to a selected date range for gadgets.
You:
Filter work items by date.
Choose ranges for data calculation.
Turn on the trim button.
This is essential to keep gadgets fast, focused, and aligned with a specific timeframe (for example, the last 30 days or the current sprint).
17. Why do my Time in Status reports sometimes look “wrong”, slow, or empty, and how can I fix that?
Most “broken” reports or gadgets come from scoping or configuration issues, not the app itself. Check:
Scope too broad – e.g.,
project = ABCwith thousands of issues over years, mixed workflows and statuses.No date filtering – missing Work items period / Report period leads to slow and noisy data.
Mixed workflows – statuses don’t mean the same thing across teams.
Unresolved items in lead-time analyses – they show open-ended times.
Report period earlier than Work items period or future-only dates – results in no data.
Work schedules not set – non-working hours included when they shouldn’t be.
To fix:
Start with clear questions (“How long did it take to resolve bugs last month?”) and set precise filters.
Use date-based scopes and realistic issue volumes.
Normalize workflows or use Status Groups to align similar statuses.
Make sure resolutions are set correctly so resolved items appear in reports.
18. What are common mistakes when using Time in Status metrics, and how can I avoid them?
Common pitfalls and how to avoid them:
Focusing on individuals, not processes
Misuse: using Assignee Time solely to judge personal performance.
Fix: focus on workflow health and team-level trends (Average Time, Status Groups, Sprint Report) and use individual data for support, not blame.
Ignoring non-working hours
Misuse: not configuring calendars, leading to inflated durations.
Fix: set work schedules and use business formats when SLAs or working hours matter.
Looking at numbers without context
Misuse: reacting to delays without asking “why”.
Fix: use metrics as a starting point for retrospectives, root-cause analysis, and process changes.
Over-relying on averages
Misuse: using only the average time, which can be distorted by outliers.
Fix: pair averages with distributions (e.g., status counts, trends, outlier investigation) and qualitative feedback.
Not keeping workflows up to date
Misuse: using outdated statuses that don’t reflect reality.
Fix: regularly review workflows and use Time in Status reports to see which statuses are actually used and how long items stay there.
Used thoughtfully, Time in Status becomes a continuous improvement tool instead of just another set of charts.
If you need help or want to ask questions, please contact SaaSJet Support or email us at support@saasjet.atlassian.net
Haven’t worked with the add-on yet? Give it a try
