What changed, and what didn't
Jira's Issue Navigator used to cap CSV and Excel exports at 1,000 issues, a limit tied to the jira.search.views.default.max property. Atlassian's own support documentation now confirms exporting up to 10,000 work items using the asynchronous Export CSV feature from the Issue Navigator is supported. That's a real improvement for teams who used to hit the wall at 1,000. It's still a hard ceiling, not pagination, and a project with more issues than that in scope runs into it the same way the old limit used to bite.
Atlassian's own workaround past 10,000
Atlassian documents the fix as a manual one: use JQL to divide your search results into smaller batches of fewer than 10,000 work items each, export each batch separately using the standard CSV export in the Issue Navigator, then manually merge the resulting files. In practice that means splitting by project, date range, issue type, or status until every slice clears the cap, running an export per slice, and stitching the CSVs together yourself, with whatever risk of duplicate or dropped rows that stitching carries.
Where this bites a scheduled report
A one-off export can absorb an afternoon of splitting and merging. A report that's supposed to refresh on a schedule can't, since the Issue Navigator's export button has no concept of a saved schedule or an automatic resume past the cap. Every refresh above 10,000 issues is the same manual JQL-split-and-merge exercise again, which is why most teams past that size stop trying to keep the CSV current and export it only when someone specifically asks.
How this differs from the JQL API limit
This 10,000-issue cap is specific to the Issue Navigator's own CSV export tool. The JQL search API most integrations use is a separate mechanism: Atlassian's own guidance on the maxResults parameter states the API returns a maximum of 50 items per response by default, adjustable but still page-based. That's a pagination problem rather than a hard export cap, since a client that keeps requesting pages can walk past it. See exporting more than 1,000 Jira issues to Google Sheets for that angle, and why Jira custom fields export as raw JSON for what happens to custom fields once the rows do land in a sheet.
No cap to split around
Sheet Sync for Jira pages through the JQL search API and continues long jobs across Apps Script runs, so a large result set is a background job instead of a manual JQL-split-and-merge exercise, and it can be put on the same hourly, daily, or weekly schedule regardless of size.
See Sheet Sync for Jira