Jira export 1000 limit: exporting a full project past the row cap

Why does a Jira export stop at 1,000 issues?#

On Jira Server and Data Center, 1,000 is the default size of a search view export: two advanced settings, jira.search.views.default.max and jira.search.views.max.limit, both default to 1,000, and Atlassian describes the cap as intentional, to avoid performance problems such as running out of memory. An export of a 4,000-issue filter returns only the first 1,000 rows.

Jira Cloud works differently. Atlassian's current Cloud guidance says the asynchronous Export CSV feature in the issue navigator supports up to 10,000 work items, runs in the background and sends an in-product notification with a download link. Atlassian's Cloud guidance gives no setting to raise that ceiling and recommends splitting the search with JQL instead.

Either way the failure mode is the same: the file looks complete, opens cleanly and simply ends. A truncated CSV gives no sign in the file itself that rows are missing, which is why the rest of this guide is about slicing, paging and reconciling counts rather than about one bigger export.

How do you get past the Jira export 1000 limit without changing settings?#

Split the project into JQL slices that each fall under the ceiling, export each slice, and reconcile the slice counts against the total before you merge anything. That works on Cloud and on Server without touching admin settings, and it is the approach Atlassian's own Cloud article recommends.

On Server and Data Center an admin can raise both settings to the same value instead. Atlassian's knowledge base says that is safe on Jira 8.2 and later but also advises against raising the limit without a very good reason, so for a one-time full export, batching is usually the lower-risk choice. Atlassian also publishes a batching script for Server that sets tempMax for the batch size and pager/start for the offset, and names each file after its first and last issue key.

Keep the CSV field choice deliberate. A separate Atlassian article says a large export from the issue search page can come back as an empty file, and recommends exporting only the fields you need. If you need every field and every comment, the API route in the next sections is usually the better tool.

How should you slice a project with JQL?#

Slice by created date first, because an issue's created date does not normally change, so date windows do not overlap and do not shift while you export. Atlassian recommends date ranges as the most flexible way to split a search, since you can shrink a window until its count fits.

Issue key ranges are the other common slice, and they make file names easy to audit. Atlassian's moved-key article uses an issuekey <= comparison, so key bounds are valid JQL, but they have one trap: an issue moved in from another project keeps a key history, and Atlassian documents that comparison operators can fail on moved issue keys, with a workaround of using a strict less-than bound. Use key ranges only after checking that the project has no moved issues, or run a created-date slice alongside as a cross-check.

Whatever the slicing field, every slice must use the same base filter, the same ORDER BY and non-overlapping, gap-free bounds. Write the bounds as half-open intervals (on or after the start, before the end) so a boundary issue lands in exactly one slice.

When should you page the REST API instead of exporting CSV files?#

Use the REST API when you need more than current field values: changelog history, every comment as its own record, attachments by ID, or a repeatable pull you can rerun. CSV slicing gets rows out; the API gets the record.

On Jira Cloud the older /rest/api/3/search endpoint is marked deprecated and is being removed. Its replacement, /rest/api/3/search/jql, pages with a nextPageToken instead of a startAt offset: you send the token from one response to get the next page and stop when no token comes back. Because the enhanced search does not return a total, pair it with POST /rest/api/3/search/approximate-count, which takes bounded JQL and returns an estimated count.

Two documented behaviors matter for completeness. Search is eventually consistent by default, so recent edits may not appear immediately; Atlassian's reconcile pattern accepts at most 50 issue IDs per request, which is useful for spot checks, not for a whole project. And the API is rate limited: a 429 response carries a Retry-After header in seconds and a RateLimit-Reason header, and Atlassian recommends using Retry-After as the minimum delay with exponential backoff and jitter.

A practical rule: freeze the export window (for example, everything created before a cutoff timestamp), run the slices, then rerun the counts a day later. If the counts for frozen windows still match, consistency lag is not hiding anything.

How do you capture changelog history and comments?#

Fetch changelogs and comments with their dedicated endpoints rather than relying on what an issue search can embed. Atlassian's platform changelog says expand=changelog on search is capped at 40 items and points to the bulk changelog endpoint to avoid that cap, so an issue with a long history comes back incomplete through expand alone.

POST /rest/api/3/changelog/bulkfetch (check its current status in Atlassian's API reference, since it was introduced as an experimental endpoint) returns changelogs for up to 1,000 issues per request, can filter to up to 10 field IDs, and pages with nextPageToken. For a single issue, GET /rest/api/3/issue/{issueIdOrKey}/changelog returns every changelog entry, oldest first, paged with startAt and maxResults. Either way, count changelog entries per issue and keep the count in the manifest.

Comments come from GET /rest/api/3/issue/{issueIdOrKey}/comment, paged with startAt and maxResults; the response reports a total and an isLast flag, so you can check that the comments you saved equal the total for each issue. The CSV export does carry comments, mapped into repeated Comment columns in chronological order, but the API keeps each comment's author, created and updated times as separate fields.

Permissions shape every response. Atlassian's docs say issues and comments are returned only where the calling account has Browse projects permission and passes any issue security or comment visibility restriction, so run the export with an account that can see everything in scope, and record which account that was.

Where do attachments and a full site backup fit?#

Attachments are separate files: list them from each issue, then download each one with GET /rest/api/3/attachment/content/{id}, using the attachment metadata endpoint for file name, size and MIME type. Store files under the issue key and attachment ID so a reviewer can trace every file back to its issue.

The Cloud site backup is the other route. In Settings, System, Backup manager, an admin can create a backup for cloud and optionally include attachments, avatars and logos; with attachments included, Atlassian requires 48 hours between backups. The backup archive is built for restoring into Jira.

A site backup is built for restoring Jira, not for reading or slicing one project. Atlassian notes that restoring it replaces all existing site data and cannot import a single project while keeping the rest of the site, and it is not laid out for review as a spreadsheet. Take it as the safety copy, and use the API or sliced CSV files as the working copy.

How do you prove the export is complete?#

Completeness is a set of reconciliations, not a feeling: the slice counts must sum to the project total, every issue key must appear exactly once, and every child record (changelog, comments, attachments) must match the count the source reported for that issue. Atlassian's Cloud article makes the first check explicit: confirm that the total across all batches matches the original query.

Run the checks in this order, and keep the output of each one with the export.

• 1Total: count the full project JQL in the issue navigator (or the approximate-count endpoint) at the cutoff and record it with a timestamp.
• 2Slices: record each slice's JQL and count before exporting, then the row count of its file; any mismatch means re-run that slice.
• 3Uniqueness: load all files, count distinct issue keys, and confirm distinct keys equal total rows. A duplicate means overlapping bounds.
• 4Gaps: for key-sliced exports, list missing key numbers and explain each one (deleted, moved out, or restricted).
• 5Children: for each issue, compare saved comments to the comment total and saved attachments to the attachment list; sample changelogs against the issue history tab.
• 6Hashes: compute a SHA-256 checksum for each file so later copies can be shown to be identical.
• 7Rerun: repeat the total and slice counts later for the frozen window; matching numbers rule out late-arriving edits.

What goes in the export manifest?#

A manifest is one small file that lets someone who was not there verify the export: what was asked for, what came back, and how the two were reconciled. Keep it next to the data as JSON or CSV, and fill it as you go rather than afterward.

What changes when the export is for a data license?#

An export that may later be licensed needs the same completeness proof plus a clear record of what was left out and why. Buyers and reviewers ask how many years and records a dataset covers, and a manifest answers that with numbers rather than estimates.

Exporting is an access question; a data license also needs privacy permission, ownership and contract rights, and de-identification alone does not create a right to license. The full four-permission framework is in the data privacy and right-to-license guide. Exclude sensitive areas such as security, HR and legal projects before anything is shared, and record the exclusions in the manifest.

SourceX is the enterprise data transaction layer for AI: it runs sourcing and qualification, rights review, contracting, data preparation, delivery and payment for businesses licensing operational data to AI developers. The company approves exactly what is released, once per deal, and the first step is a short company assessment with no data uploads needed. SourceX does not operate a Jira connector; the export steps here are run by your own team.