How to export Jira issue history to Excel or CSV

Current fields or change rows?

A useful history export has one row per field change: the work item, time, person or automation, field, previous value and new value. One work item can contribute several rows.

For example, a task can be Done today after moving from To Do → In Progress → Done. Its current status answers “where is it now?” The two transition rows answer “what happened?” Saving a current-fields CSV as an Excel workbook does not add those missing events.

1. 01

   Which work items?

   A space, saved filter or JQL query selects the items accessible to you now.

   Example: the Operations space
2. 02

   Which changes?

   The change period, time zone and field filters determine the event rows.

   Example: status changes in August, UTC
3. 03

   What did you cover?

   Keep the selection, dates and any gaps alongside the exported changes.

   Deliver: change rows + report scope

A report period filters when changes happened. It does not reconstruct which work items belonged to a space at that time.

Start with one work item in native Jira

1. Open a work item with a change you already know about.
2. Find Activity and select History.
3. Record the field, before and after values, who made the change and the timestamp. Note the time zone used when you compare it with a report.
4. Compare that event with the field’s current value in the work item details.

In our Cloud check, Organizations had been filled with a test organization and then cleared. Jira showed both changes, although the current field was empty. An empty field did not mean it had always been empty.

01Find a known change first

A manual record may be enough for a few events

For a one-off question about two or three changes, copy the relevant events into a small table. Include the work item link, timestamp and time zone, who made the change, field, previous value and new value. Add a note stating which items and dates you checked and when you checked them.

Label it a manual extract. Do not call it a full export if you only copied selected events. If Jira does not show who made a change or one of the field values, record it as unknown.

Check what the standard CSV export answers

To export the current work item fields, open Filters → Search work items. Select your items, then open More actions → Export → CSV – all fields. In the Cloud interface we checked, the menu also offered Excel CSV – all fields and variants for visible fields. Atlassian describes the native workflow in Export issues from Jira Cloud in CSV format.

Open the CSV and inspect its headers before using it as evidence. Current fields such as Status, Assignee and Updated do not give you a separate who/when/before/after row for every historical change. The all fields option can include comments, as Atlassian documents; comments and field-change events are different kinds of information.

If you only need the current backlog, stop here. If you need past field changes across several items, choose a method that reads the changelog.

Choose an export method

Scroll the table horizontally to see all columns.

An integration can retrieve history through Atlassian’s changelog API. It needs to read every page of results. Consider this route if your team has someone who can maintain and validate it.

For an app route, History Steward produces field-change rows with a separate report scope. I build this app, so the walkthrough below shows its actual output and limits. Another option is SaaSJet’s Issue History for Jira, whose listing includes Excel and CSV exports. Compare the features and edition you need; this guide is not a comparative product test.

If your question is “how long did each item spend in a status?”, look for a report that calculates durations. History Steward exports events; it does not calculate time in status.

Export changes with a defined scope

The following example uses History Steward with a synthetic Operations dataset in a local test environment. It contains three work items and seven changes in August 2026. The sample files below use the same dataset. They do not contain the Cloud work item shown earlier.

Select work items and change dates separately

1. Open Apps → History Steward on a site where it is installed.
2. Choose Space, Jira filter or JQL. Select the work items you need, then choose Check work items. Review the count and selection before continuing.
3. Set Changes during and Report time zone. For this example, use 1–31 August 2026 and UTC. Both calendar dates are included.
4. Select Load history. Then use Fields, Changed by, Before or After to narrow the loaded changes.

02Define the selection and period

Be careful with a query such as project = OPS AND status = Done. It selects items whose status matches when you run the query. It can omit an item that changed status in August but is now reopened. Select all work items relevant to the review, then filter their historical changes.

The app checks accessible items now; it does not reconstruct past space membership. The export uses current work item keys and summaries alongside the historical before and after values.

Open both Changes and Scope

Select Export Excel for an XLSX workbook with Changes and Scope sheets. Select Export CSV for a ZIP containing changes.csv and scope.json. Keep the two parts together when you share the result.

03Read the events alongside their coverage

In the downloadable sample’s Changes sheet, find OPS-101: its status changes from To Do to In Progress on 5 August at 09:15 UTC, then from In Progress to Done on 20 August at 08:00 UTC. In Scope, confirm three selected work items, seven delivered changes, the August period and UTC. One of the three selected items has no changes in this period, so three selected items do not mean three distinct keys must appear in the event rows.

Validate the result before sharing

For an export from your own Jira site, match the known History event you checked earlier: work item, field, before and after values, and timestamp in the report’s time zone. For the downloadable sample, use the OPS-101 events described above; it contains synthetic data, not the Cloud work item in the first screenshot. Then check the scope:

• Selection and period: do the items and change dates match the question you are answering?
• Filters: did a field, actor or value filter intentionally remove some rows? The sample has seven rows before filters.
• Coverage: were all selected items processed, and are any gaps or excluded items reported?
• File contents: do the delivered row count, date range and coverage agree with the report? Preserve Scope when copying or sharing Changes.

Complete means History Steward finished reading the available history for the selected work items you can access, with no known gaps. It does not guarantee every change ever made, recover deleted work items or establish a site-wide audit trail.

If the report is Partial, read the reason before using the rows. In the interrupted-read example below, the app retained three changes but had not finished reading the full history of any of the three selected items. That result needs a coverage note; it cannot support “there were no other changes.” Retry after a temporary problem, or split the selection and keep a record of each part.

04Keep known gaps visible

History Steward rechecks access before each export and excludes work items that are no longer accessible. Exporting a partial result requires an explicit confirmation. Its limits include 1,000 selected work items and 100,000 retained changes; other processing limits can stop a report earlier. A shorter date range can produce fewer rows, but the app may still need to read older history to find them.

Comments, worklogs, deleted-item recovery and scheduled reports are outside this app’s field-history workflow. The History Steward user guide covers filters, value states, permissions and export details.

To see whether this format answers your own review question, explore the History Steward sample before choosing an export method.

How this guide was checked: on 14 September 2026, we inspected native Jira Cloud History and the search export menu, then matched two test-organization changes in an installed development build of History Steward. The app screenshots and downloadable sample files use a separate, synthetic local dataset. We checked the sample Excel/CSV rows and scope, and reproduced an interrupted read. This is a workflow example, not a production-scale benchmark. Product availability is stated on the History Steward page.