Jira time in status vs time spent: two clocks for different decisions

Time in status measures how long an issue occupies a workflow state. Time spent measures effort recorded in worklogs. An issue can wait in review for two days while a reviewer logs one hour. Both values can be correct.

Use workflow duration to investigate flow and waiting. Use logged effort to investigate work performed, reporting completeness, and effort against an estimate. Define the calculation before comparing the values.

Follow one issue through both clocks

This example is synthetic. All event times use the same timezone, and elapsed hours include nights. No daylight-saving transition occurs in the example.

The issue spent 35 elapsed hours in In Progress across two visits, and 42 in In Review. Suppose contributors logged six hours of implementation, one hour of review, and two hours of fixes. Total logged effort is nine hours.

It would be incorrect to say the developer worked 35 hours merely because the issue had that much In Progress time. It would also be incorrect to infer exactly 68 hours of avoidable waiting by subtracting nine person-hours from 77 elapsed hours. The clocks measure different things.

Make the calendar explicit

If a report instead counts only Monday–Friday, 09:00–17:00, with no holidays or excluded lunch break, the review interval in this example is ten working hours: eight on Wednesday and two on Thursday.

That is a valid alternative to 42 elapsed hours, provided the calendar is clearly labeled. A team in another timezone or with a different working calendar can produce a different result from the same transitions.

Record whether a report uses calendar time, business hours, or an SLA-specific calendar. Do not compare those numbers as if they share a unit definition.

Distinguish one status from a cycle-time boundary

A cycle-time measure generally spans a defined part of the workflow. It can include several statuses and repeated visits. A time-in-status report may instead show each status separately.

Atlassian's Control Chart documentation explains how selected columns affect the duration being measured. Check its configuration before interpreting a point as time in one particular status or as the team's total logged effort.

Choose the boundaries your decision requires. If the question is how long review takes, define which states count as review. If it is customer lead time, a boundary beginning only when development starts may omit relevant waiting before that point.

Handle repeated and unfinished visits

An issue that returns to In Progress should not lose its earlier visit. Establish whether the report sums every included interval, displays only the latest visit, or uses another documented rule.

For an issue still in a status, define the end of the open interval: usually the report's capture time under your chosen convention. Record that timestamp so someone can reproduce the duration later.

Also review imported history, renamed statuses, and transitions that happened before the reporting window. Missing history should appear as a limitation rather than an invented start time.

Choose the report by the question

For effort forecasting, use the estimated-versus-actual example. For selecting a tool category, see the Jira time-app comparison.

Use both metrics in the same investigation

Suppose review duration rises while logged review effort stays similar. That is a reason to inspect queueing, ownership, and handoff timing—not proof of a particular bottleneck. Look at issue history and discuss examples with the team.

Suppose logged effort rises while workflow duration stays stable. That can prompt a different question about scope, collaboration, or recording practices. Again, the numbers identify something to investigate; they do not supply the cause.

TimePillar is positioned around Jira effort reporting and roll-ups. If your primary need is duration in workflow states, verify a tool's status-history and calendar support explicitly. Do not assume a product called “time tracking” measures every clock.

Start with one issue whose transitions and worklogs you can inspect manually. A report that explains that example clearly is a better foundation than a dashboard full of undefined averages.