Jira Time in Status Export to Excel — and How to Get It Every Monday

A Jira time in status export to Excel is two problems wearing one name. The first is getting the rows out of Jira, and the native CSV does that in a click. The second is getting durations into them, which the native CSV cannot do, because time in status is not a field. What follows is what the native export really contains, the formula route over the changelog and what it costs to maintain, and how to produce a file with the durations already computed — including on a schedule, so that nobody has to remember to produce it at all.

Why the report has to leave Jira

Every time-in-status question eventually ends in a spreadsheet. Not because Jira's charts are bad, but because the people who act on the numbers rarely live in Jira. The person who needs the answer often has no Jira licence and no interest in acquiring one — a delivery manager assembling a board deck, a client contact checking an SLA clause, a finance analyst reconciling capitalised work. A chart on a dashboard they never open is the same as no chart at all.

There are quieter reasons too. A spreadsheet lets you pivot the same rows three different ways in an afternoon, which no fixed report view will. It gives you an archive — export the same filter on the first of every month and you have a trend Jira itself never shows you, because Jira reports describe now. And it survives the meeting: a file attached to the minutes is still the same file a quarter later, when the dashboard has moved on.

So the data has to leave Jira cleanly, with the durations already computed. That last clause is where the native options fall short, and it is worth being precise about how.

What Jira gives you natively

Jira Cloud has a perfectly good CSV export on issue search — Export issues from any filter, open the file in Excel, done. The catch is what the file contains: the current value of each field. The Status column says Done. How long the issue sat in In Review before that, how many times it bounced back to In Progress — none of it is in the file, because none of it is a field. Status history lives in the issue changelog, and the changelog is not part of the issue-search export.

Jira Cloud for Excel, Atlassian's official add-in, pulls issue fields straight into a workbook and refreshes them on demand, which solves the copy-paste half of the problem and none of the duration half. For the history itself the route is the REST API's changelog endpoint: one row per transition, with a timestamp, an old value and a new value. That gets you the raw material. The gap between two timestamps exists only once someone computes it, and in this route that someone is you.

Which brings us to the formula approach. It works. It is also worth seeing in full before you commit to it.

The Excel formula route over the raw changelog

Suppose you have pulled the status transitions into a sheet, sorted by issue key and then by timestamp:

The duration of each visit is the gap to the next row of the same issue. A helper column does the pairing — with the data in columns A through D, row 2:

=IF(A2=A3, B3-B2, IF(D2="Done", 0, NOW()-B2))

Each row's result is the time the issue spent in the status it entered on that row (column D), so a second sheet can pivot it into one row per issue with a SUMIFS per status:

=SUMIFS(Changelog!$E:$E, Changelog!$A:$A, $A2, Changelog!$D:$D, C$1)

Format the results as [h]:mm, and for a few dozen issues this is a legitimate answer. If you only need it once, it may well be the right answer; how the same calculation is done properly is the reference to check it against.

The trouble starts when the sheet has to be correct rather than roughly right:

• The first interval is missing. Creation to the first transition — the time in To Do — has no changelog row of its own. You need a synthetic row per issue built from the created date, or your backlog numbers silently collapse to zero.
• Pagination. The REST API's expand=changelog returns at most the first 100 history entries per issue; beyond that you are paging through the changelog endpoint yourself. A two-year-old issue on an active board passes 100 entries without trying, and a sheet built on truncated history looks exactly like a sheet built on full history.
• Re-entries. PROJ-118 above visited In Progress twice. The SUMIFS handles the arithmetic, but every downstream consumer of the sheet has to remember that one cell may hide three visits.
• Business hours. B3-B2 counts weekends and nights. Subtracting them — per weekday schedule, per time zone, minus public holidays — turns a helper column into a project. Most sheets quietly skip this step, and then the numbers get compared against a team's working-hours intuition anyway.
• It rots. The workbook is correct on the day you build it. Someone renames a status in the workflow, and the SUMIFS headers stop matching; nobody notices until the numbers look odd in a review.

None of this is an argument against the approach for a one-off. It is an argument against maintaining it monthly.

Exporting Time in Status to Excel, step by step

Time And History computes the durations before the export, so the file that leaves Jira already contains the answer. The Time in Status report builds one row per issue with a column per status — the pairing, the first interval, the re-entries and the full changelog pagination are its problem, not the spreadsheet's. Here is the whole procedure:

1. Open the report and narrow the filter. Pick the project, then optionally epics, sprints, reporters, assignees, and a date preset over created, updated or resolved dates. The filter defines the export exactly — what matches the filter goes into the file.
2. Set the clock before you export. Choose the work calendar (business days, hours, holidays, time zone) and the time format. If the spreadsheet is going to do arithmetic on the durations, pick Decimal Hours or Decimal Days here — those formats exist precisely so that Excel can sum and average the columns without parsing 1d 1h 43m. Note the caveat below.
3. Add the columns the reader will ask about. The Columns selector searches every Jira field, system and custom — labels, priority, a "Customer" field of your own — so the recipient can pivot without a second lookup export.
4. Press the export button in the controls row and choose the format: MS Excel Report (.XLSX), Plain Text Report (.CSV), or Chart Image (.PNG) while chart mode is open. Since 2.3.0 all five reports have chart mode, so the PNG is offered on all five.
5. Let the job run. The export runs in the background over every issue matching the filter — not the visible page — with a progress bar in the Export history panel. A large filter takes a while because the durations are computed on the fly from the Jira REST API; you can change filters or leave the page meanwhile.
6. Download from Export history. The panel keeps your twenty most recent exports with their status — In Queue, In Progress, Success, Failed — for re-download or deletion. Files are private to whoever created them.

What lands in the file

The XLSX is a real workbook, not a CSV with an .xlsx extension. The Issues sheet is the table you saw on screen — issue key, type, summary, assignee, one column per workflow status found in the filtered issues, and Total Time From Create Issue at the end. In Decimal Hours it looks like this:

A status the issue never visited shows - rather than a zero, so an empty cell never reads as "fast" in a pivot table. The columns come from the data, not from configuration — filter a project with a Waiting on Customer status and the column appears on its own.

Any Between Statuses pairs you picked come with it. Add In Progress → Done on the report and the file gains a column headed In Progress → Done (first exit) — the working time between the two statuses, per issue, in both XLSX and CSV.

Time in Status, Assignee Time and Time to Resolution always add a sheet of chart data: totals and percentages per series, ready to feed a chart of your own or to sanity-check the one in the deck. Transition Count gets a totals sheet in its place, because its Issues sheet carries no totals row. Exported from chart mode, the workbook also carries the chart images — for the reader who will never open Jira.

The CSV is the same issues table as plain text with a UTF-8 byte-order mark, so Excel opens it with the arrows and accented names intact instead of mojibake — the right choice when the destination is a script, a BI pipeline or a data warehouse rather than a human. It carries the table and nothing else: the chart-data sheet is an XLSX feature. The PNG is a snapshot of the open chart, for the reader who needs one picture and no table at all.

All five reports export, not only Time in Status — Assignee Time, Time to Resolution, Time in Changes and Transition Count use the same button, the same background job and the same history panel. The Transition Count workbook adds a totals sheet, because counts add up in a way durations do not. The exporting documentation is the authoritative list of formats and sheet contents.

Get the same file every Monday

An export is a snapshot of a filter at the moment the job ran. Which is fine, until the snapshot has to be taken every Monday before a 9:30 call — because then it is a recurring task on a person, and recurring tasks on people are how reporting quietly stops happening.

Since 2.3.0 the app takes it instead. Set the filters on the report page, open Scheduled Reports and create a schedule — and note the order: the filters have to exist on the page first, because the schedule takes a snapshot of them and the snapshot is fixed when the schedule is created. Changing the report page later does not change a running schedule; you edit the schedule, or make another one.

What a schedule holds:

• Any of the five reports, with the filters frozen as you set them.
• Daily, weekly or monthly, from a start date and a start time in a time zone you pick, so "every Monday at 09:00" means 09:00 where the readers are, not where the server is.
• Up to ten recipients, typed in by whoever creates the schedule. Nobody is subscribed implicitly, and no Jira group is expanded into a mailing list — if you want the file yourself, add your own address.
• The XLSX attached to the mail, when the file is 7 MiB or smaller. Above that the mail arrives without the attachment and says the owner can download it from Export history instead. A schedule always sends XLSX; CSV stays a manual export.
• Every run listed in Export history, in the same twenty-file panel as your hand-started exports. The panel does not badge them, but the file name does: a scheduled file is stamped Scheduled where a manual one says Filter or Chart.

One property to understand before you add a stakeholder to the list: a scheduled run collects as the schedule owner, so every recipient sees the owner's view of Jira. On the report page the opposite is true — every Jira read runs as the person looking at the screen, so two viewers of the same filter can legitimately see different numbers. That is deliberate in both directions, and it is the reason a schedule is worth creating from an account whose Jira permissions match what the audience is allowed to see.

The free route

If your site has ten Jira users or fewer, Time And History is free — which makes "export Jira status history to Excel free" a solved problem rather than a search query: install, open Time in Status, filter, export. Above ten users there is a trial to establish whether the report answers your questions before anyone signs anything. Pricing is the most perishable fact on this page; it was verified on 6 September 2026 and the listing is the authority.

And the DIY route remains a fair answer for a genuinely one-off need — a single retrospective, one issue's history, an audit question about who changed what and when. For that last case the changelog itself is what you want rather than a duration, and Time in Changes reads it as a report: who changed the status, when, from what to what, and how long the old value lasted. For everything recurring, the arithmetic belongs in the tool and the judgement in the spreadsheet — and which of those numbers survives the trip into a meeting is worth settling before the first file goes out.

Jira time in status export to Excel FAQ

Can Jira export time in status to Excel natively?

No. The native issue-search CSV export carries each field's current value, and time in status is not a field — it is a calculation over the issue changelog, which the export does not include. Jira Cloud for Excel can pull issue fields into a workbook, but the duration arithmetic over the changelog is yours to build.

How do I export Jira status history to Excel for free?

For ten or fewer Jira users, Time And History is free: open the Time in Status report, filter, and export XLSX or CSV. Without an app, pull changelog rows via the REST API and compute the gaps with formulas — workable for one-offs, fragile as a recurring process.

Does the export include all issues or only the visible page?

All of them. The export runs as a background job over every issue matching the current filter, with progress shown in the Export history panel — the visible page is just a window onto the same result set.

Should I export XLSX or CSV?

XLSX when a person will read the file: it carries the Issues sheet, the chart data with totals and percentages, and the chart images when exported from chart mode. CSV when a machine will read it — one issues table, UTF-8 with a byte-order mark so Excel still opens it correctly, ready for scripts and pipelines. Scheduled reports always send XLSX.

Can Jira email a time in status report on a schedule?

Yes, since version 2.3.0. Set the filters on a report page, then create a schedule: any of the five reports, daily, weekly or monthly, at the start date, time and time zone you choose, mailed as an XLSX to up to ten recipients you type yourself. The filters are frozen when the schedule is created, and every run appears in Export history. The run collects as the schedule owner, so recipients see the owner's view of Jira.

Do the exported durations respect business hours?

Yes, if the selected work calendar says so — durations are computed against the calendar's weekday hours, holidays and time zone, and the export reflects whatever the report showed. The exception is the decimal formats, which sum to 24-hour days and ignore business days; use them when you want wall-clock arithmetic in the spreadsheet.

Export it once, then stop exporting it

Do the manual version first, once: open Time in Status, pick one project and the sprint that just closed, set the work calendar, press Export, and open the XLSX. It takes about two minutes and it tells you whether the columns are the ones your audience asks about. Then, if the answer is yes and the same file will be wanted next Monday, spend one more minute turning that exact filter into a schedule and take the task off your calendar for good.

Time And History for Jira Cloud is five reports built from Jira's issue history — Time in Status, Assignee Time, Time to Resolution and Time in Changes in business hours, plus Transition Count, which counts status changes rather than hours — each exporting to XLSX and CSV, and each able to arrive by email on a clock. Install it from the Atlassian Marketplace, or read the scheduled reports documentation first. Free for up to 10 users · verified 6 September 2026.