The good news first: Jira already has the data. Every status change on every issue is recorded permanently, in the issue's History tab and in the changelog API behind it. Nothing is missing and nothing has to be switched on in advance.
What Jira does not have is a report that turns that history into "this issue spent 4 days in In Progress". That one step — history into durations — is the entire gap, and it is why a whole category of paid apps exists.
Here is every way to close it without buying one.
1. The History tab
Open an issue, scroll to History, and read the status changes with their timestamps. Subtract by hand.
Good for: settling an argument about one issue. It is exact, complete, and available to anyone who can see the issue.
Stops at: two issues. There is no export, no sorting, and no total. Nobody has ever done this for a sprint twice.
2. Days in column
A board setting that puts grey dots on each card, one per day in the current column.
Good for: spotting the one card that has been sitting too long, at a glance, with zero setup cost.
Stops at: three things. It shows dots rather than a number, so you count them. A project admin has to turn it on, which is exactly the person you were trying not to ask. And it resets when an issue leaves the column and comes back, so a ticket that has really been in progress for nine days across three attempts can show one day.
The full write-up on Days in column, including how to switch it on and what the dots actually count.
3. The Control Chart
Built into Jira Software reports. Plots cycle time for completed issues as a scatter with a rolling average.
Good for: the trend. Is the team getting faster or slower over a quarter.
Stops at: the individual issue and the individual status. You cannot read "CMS-42 spent 6 days in code review" off a scatter plot, and it does not break the time down by status at all, which is usually the question you actually had.
4. Jira Automation into a custom field
The standard free advice, and the one worth reading carefully. You build a rule: when an issue transitions, work out how long it sat in the status it just left and write that into a custom field. Then the field is sortable, filterable, and visible on a board.
Good for: one or two statuses you care about permanently, on a team willing to maintain automation rules.
Stops at everything that already happened. A rule can only fire on a transition that occurs after you create it. On the day you finish building it, every issue on your board reports nothing, and the ones that matter most — the ones that have been stuck for weeks — are exactly the ones it can never measure, because they are not going to transition again soon. You wait a full cycle before the data means anything. This is the limitation that almost no guide states plainly.
It also costs a custom field per status, and automation executions are metered on most plans.
5. The REST API, with a script
The honest technical answer. The changelog endpoint returns every status change with a timestamp, and the durations are subtraction from there.
GET /rest/api/3/issue/{issueKey}/changelog
Filter the entries to items[].field === "status", sort by
timestamp, and each consecutive pair is an interval. The issue's creation
date opens the first one; now closes the last.
Good for: anything, because it is just code. It works retroactively across the entire history, which is the thing Automation cannot do.
Stops at: needing to be written, and then needing to be
run by someone every time anyone wants the number. Two details bite in
practice: the bulk endpoint
/rest/api/3/changelog/bulkfetch returns timestamps as epoch
milliseconds while the per-issue one returns ISO 8601 strings, and a
status can be renamed after an issue passed through it, so you must key
intervals by status ID rather than by name or your columns quietly
split in two.
6. A free marketplace app
Free tiers exist. They are real options and worth knowing about.
Stops at: the install. A marketplace app is installed onto the Jira site, so a Jira administrator has to approve it — which for many people is the whole reason they are reading this page. Free tiers are also usually rate limited, and the paid upgrade is licensed per user on the site rather than for you.
Side by side
| Method | Per status | Covers the past | Needs an admin |
|---|---|---|---|
| History tab | Yes | Yes | No |
| Days in column | Current only | Current visit | Yes |
| Control Chart | No | Yes | No |
| Automation | Yes | No | Usually |
| REST API script | Yes | Yes | No |
| Marketplace app | Yes | Yes | Yes |
What we built, and why
TimeInColumn is method 5 without the script. It is a Chrome extension that reads the same changelog through your own browser session and shows the durations on the Jira pages you already have open: a badge on every card and issue, a breakdown of every status an issue passed through, and a report across a whole project you can sort and export.
Because it runs in your browser rather than on the Jira site, no administrator has to approve anything, and because it only ever talks to your own Jira, none of your issue data reaches us — there is no server of ours for it to reach.
It also answers the question Automation cannot: it measures history that already happened, on the first page load, including the ticket that has been stuck since August.