Haulcopy

Checked against Atlassian’s docs on 17 Oct 2026

Export more than 1,000 Jira issues

For years the practical answer was “Jira stops at 1,000.” That changed for the Cloud navigator export on 19 March 2025. The ceiling is now 10,000 for one asynchronous CSV, and it is still a ceiling. Past 10,000, Jira’s own instructions are to split the JQL yourself and merge the files.

1,000 was the old navigator cap

Atlassian’s March 2025 note, Export up to 10,000 items from Jira, says the issue navigator CSV and Excel export had been capped at 1,000 issues, and that the asynchronous export was raised to 10,000 on 19 March 2025 (Sydney/Melbourne time). The REST API was not raised with it. If a script still pages 1,000 at a time, that script is doing what the API still expects.

If a search under 1,000 fails, the cap is not the cause. A 414 on a complicated JQL is an authentication-redirect problem Atlassian documents separately. A tiny JQL once, then the real one, is their workaround for that error. It is not a way to beat the row cap.

10,000 is the current navigator cap

Export over 10,000 work items in Jira Cloud says the asynchronous Export CSV from the issue navigator supports up to 10,000 work items. The export runs in the background. A download link arrives as an in-product notification. “Export CSV (all fields)” and “Export Excel CSV (all fields)” can be slow and huge. Prefer current fields or filter fields when you can.

The same article’s first workaround, paging with pager/start through Google Sheets or Excel in batches of 1,000, is marked deprecated as of March 2026. Do not mix that URL method with the UI export. Atlassian says mixing them can duplicate or drop work items. If you still use the deprecated URL, use it for every batch, not for some of them.

How to split a search that is over 10,000

Atlassian’s remaining workaround is JQL. Cut the search into pieces that each return fewer than 10,000 work items, export each piece, and merge the CSVs. Their rules:

  1. Check the count in the navigator before you export. If a piece is still over 10,000, narrow it again.
  2. The pieces must not overlap, or the merge will repeat issues. A date window, a key range, or ORDER BY key plus a key bound are the usual cuts. A status clause that issues move through will miss or double-count if you are not careful.
  3. Export each piece with the same columns, or the merge has nowhere to put the extra fields.
  4. Keep the header row from the first file only.

Jira Cloud for Sheets stops at 10,000 per import as well. The documented continuation is a second =JIRA() call with a start offset of 10000, on a sorted JQL. That path is described on export Jira issues to Excel.

What Haulcopy does with the same line

Haulcopy uses 10,000 as the size of one file, not as the size of the search. A larger JQL is written as separate files of 10,000 issues. You do not rewrite the JQL. The page shows progress. Only one export runs at a time on the site, so a second request waits.

The customer-sized run that was measured is the 10,000-issue, 50-field Excel file on 16 Oct 2026, on a developer site. A later smoke forced a 500-row part size on 1,500 issues and got three Excel files, which only shows that the writer can emit more than one part. The part size in the product is 10,000, so a 1,500-issue export is one file. A 25,000-issue export on a live Jira site has not been run. The offline plan for 25,000 rows is three parts of 10,000, and the unit test writes one file per part.

Jira’s rate limits still apply. Haulcopy does not skip them. It waits, shows progress, and continues. Files expire after seven days. Docs. The Marketplace listing is not published yet.