During a sprint review, someone might ask why a certain issue has been in progress since last week. You open the issue, review the history, roughly count the days, and still can’t give a definitive answer. Jira records every status change, but it doesn’t show how long an issue has spent in each status. This metric shows, for example, that an issue has been in the “In Review” status for 6 days. And it’s this data that allows you to identify bottlenecks, stalled work, and other insights that aren’t visible in native reports.
This guide is for those people who get asked that question: Scrum Masters, project managers, and support leads. We’ll cover whether Jira has a native time in status field, the possible native ways of tracking this data, and how to add a Jira time in status custom field that counts working hours, not raw 24/7.
Does Jira Have a Native Time in Status Field?
No, Jira Cloud does not provide a built-in field that shows how long an issue has spent in a specific status. While Jira stores the underlying transition data, it does not offer a ready-made duration field that can be displayed in the issue view, on board cards, or used directly in JQL queries.
In other words: Jira tracks transitions, not durations. The history is there, but turning it into “time in status” requires either manual configuration or a dedicated app. Below are the native options, what they’re good for, and where they stop being practical.
Native Ways to Track Time in Status in Jira (and Where They Break)
Custom field + automation rules
The most common DIY approach is to create your own custom fields and use Jira automation to capture timestamps when an issue enters and leaves a status, then calculate the difference.
It works on paper, but it scales badly:
- You need a separate rule (and often separate start/end date fields) for every status you want to measure.
- It only starts collecting data from the moment you build it — there’s no history for issues that already moved through the workflow.
- Reopened issues and rework loops break the math, because the rule has to keep summing repeated visits to the same status.
- Maintaining a growing web of automation rules and number fields becomes its own project.
It’s a reasonable experiment for one or two statuses. It’s not a reporting system.
Control Chart
Jira’s built-in Control Chart visualizes cycle time across issues and is genuinely useful for spotting trends at the board level.
Its limits for time-in-status work:
- It gives you board-level averages, not a clean per-status breakdown across many issues.
- It calculates on a 24/7 clock, so nights, weekends, and holidays inflate your numbers.
- It lives in the report area — it doesn’t put the value on the issue card where the team actually works.
Why JQL alone isn’t enough
This is the wall most teams hit. JQL is excellent at filtering issues by their status history — for example, finding everything currently in Review, or everything that ever passed through Blocked. But JQL cannot calculate time durations. It can tell you that an issue is in a status; it can’t tell you how long it’s been there.
So the moment you want “show me issues that have been in Review for more than 2 days,” native JQL leaves you guessing. That gap is exactly what a real time in status field closes — and as you’ll see below, the right field becomes searchable in JQL too.
Jira Time in Status Custom Field (the Effortless Way)
The Time in Status app adds a proper Jira time in status custom field: you create the field once, and the time an issue has spent in a status (or group of statuses) appears directly on the issue and on the board card — calculated by your team’s working calendar. No automation rules, no manual date fields, no broken math on reopened issues.
Full setup steps are in the Custom Fields documentation. Here’s the short version.
How to create a Time in Status custom field
- Open the board for the project you want to track.
- Select Time in Status Agile Board from the dropdown in the top-right corner.
- In the modal, enter a name for your custom field and select the working schedule (calendar) used to calculate the time.
- Choose what you want to measure — a single current status, or a group of statuses for a metric.
Then associate the field with a screen (Jira settings → Work items → Custom fields → find your field → Associate to screen) and, if you want it on cards, add it via Board settings → Card layout.
Current status vs. grouped statuses
The field works in two modes:
- Time in the current status — shows how long an issue has been sitting in its current status. Ideal for spotting stuck work at a glance.
- Group statuses to get a metric — combine several statuses into one field to calculate exactly the metric you care about:
- Lead Time — group all statuses except the final one (everything before “Done”): total time from creation to completion.
- Active Time — group only the hands-on statuses (In Progress, In Review, Testing), excluding waiting states.
- Cycle Time — group the statuses that make up your delivery phase.
- Time to Resolution — group from the first active status through “Resolved/Done.”
This is the difference between a raw number and a metric your team can act on.
Business-hours accuracy
Every custom field is tied to a working calendar, so the time it shows reflects your real schedule — working days, working hours, breaks, and holidays — rather than counting around the clock. A ticket that sits over a weekend doesn’t get punished for it. For teams managing SLAs or comparing actual vs. planned delivery time, this is the part native Jira simply can’t do.
The value displays in dd:hh (days:hours) format and updates automatically: roughly once an hour in the background, within seconds when an issue changes status, and again whenever someone opens the issue.
Use the field in JQL
Because the custom field has a real field name, you can use it in JQL, which finally lets you filter by duration, not just by status history. For example:
status = "In Progress" AND "TIS [Review]" >= 2hThat returns issues currently In Progress that have already spent at least two hours in Review. This is precisely the “how long, not just where” query that native JQL can’t express on its own.
Common Use Cases for a Jira Time in Status Field
Once the time is visible on the issue and searchable in JQL, the same field powers a handful of everyday jobs:
- Monitor SLA breaches — because time is calculated in business hours, the field reflects your real SLA clock. Use it in JQL (e.g., issues that have spent more than a set time in a support status) and pair it with Jira automation to flag or notify on breaches before they happen.
- Identify stuck issues — the current status mode shows how long an issue has been stuck where it is. Put the field on the card layout, and stalled work becomes obvious at a glance, no report needed.
- Track review delays — measure time specifically in Review (or Code Review) and filter with a query like “TIS [Review]” >= 2d to surface everything sitting in review too long.
- Measure cycle time — group your delivery statuses into a single field to get cycle time per issue, calculated using your working calendar — not a 24/7 estimate.
- Improve support response times — track time in “Waiting for Support” or “In Progress” against business hours to see where tickets lose time and which stages need attention.
In each case, the field does the same thing — turns Jira’s hidden transition history into a number you can see, sort, and act on.
Good to Know Before You Set It Up
The custom field is designed to stay accurate and lightweight, which means a few intentional constraints:
- Company-managed (classic) boards only — the field isn’t available on team-managed boards.
- Admins create it — only Jira administrators can create Time in Status custom fields. If you don’t see the option, ask your admin to update the app to the latest version.
- Board-specific — a field works only on the board it was created on.
- 30-day data window — the field shows data for items updated within the last 30 days.
- Rightmost column isn’t calculated — by design, since time in the final status (e.g., Done) usually isn’t relevant, especially on Kanban boards.
- Calendar is locked after creation — you can’t re-link a field to a different calendar later, though you can still edit the linked calendar’s settings.
- Watch for unmapped statuses — statuses not mapped to board columns don’t get the hourly auto-update; review your board settings if a value looks off.
None of these are workarounds — they’re guardrails that keep the field fast and the numbers trustworthy.
Beyond a Single Field — Full Time in Status Reports
A custom field is perfect on the card and in JQL. But when you need to analyze across many issues — find the slowest status in a sprint, audit SLA breaches, or compare assignees — you’ll want the report views in the same app:
- Average Time — average duration per status across a set of issues.
- Status Count / Transition Count — how often issues enter a status or move between statuses (great for spotting rework loops).
- Assignee Time — total time an issue is spent with each assignee.
- Pivot Table View — custom, multi-dimensional breakdowns of your status data.
- Chart Reports — visualize any report as Pie, Column, Area, or Sunburst charts, with trendlines on column charts for spotting trends.
The field answers “how long is this issue stuck?” The reports answer the question: “Where does our whole workflow lose time?” Together, they take you from a single number to a decision.
Ready to add a real time in status field to Jira? Try Time in Status free on the Atlassian Marketplace or request a demo.
FAQ
Does Jira have a built-in time in status field? No. Jira Cloud has no native field that shows how long an issue has spent in a status. Jira stores status-transition history, but surfacing duration requires automation, the Control Chart, or a dedicated app.
Can I see the time in status directly on the Jira issue card? Yes — with a Time in Status custom field. Once it’s associated with a screen and added to the card layout, the time appears right on the board card and inside the issue.
Can JQL calculate time in status? Native JQL can filter by status history, but cannot calculate durations. With a Time in Status custom field, you gain a field name you can query by duration, e.g., “TIS [Review]” >= 2h.
How is time in status calculated with business hours? Each custom field is linked to a working calendar that defines working days, hours, breaks, and holidays. Time is calculated against that schedule rather than a 24/7 clock, so nights and weekends don’t inflate the numbers.
Does it work on team-managed boards? No. The custom field is available on company-managed (classic) boards only, and only a Jira administrator can create it.
What metrics can a grouped status field show? By grouping statuses, you can calculate Lead Time, Active Time, Cycle Time, and Time to Resolution for each issue — each aligned with your working calendar.