Atlassian is adding a total size cap of 500 MB per work item to Jira Cloud from November 2026. Everything counts except the binary files in attachments. Most sites will never notice. The ones that do will find out when a write fails with a 413, usually from an integration nobody has looked at in two years.
This post is about finding those items now, with the REST API you already have, before the limit finds them for you.
What the limit actually covers
From @Snehal Shah's announcement (12 October) and the updated Work item field limits page:
- Included: comments and worklogs, description and the standard fields, custom fields (plain text, URL, numeric, select, rich text), issue properties (app data attached to the item), issue links, remote links and web links, voters and watchers, sprint, SLA, approvals and history metadata.
- Excluded: the binary content of file attachments. Attachments keep their own limits.
- When exceeded: the write is rejected, the API returns 413 Payload Too Large, and nothing is saved. Existing items already over the line get a one-time, non-destructive cleanup: older comments (except those with custom visibility) are zipped and attached to the item.
The existing per-field caps do not protect you from this one. The KB caps a plain text or URL custom field at 25 MB and a comment at 1 MB, with up to 5,000 comments per item. Twenty full plain-text fields, or a few thousand large comments, reach 500 MB inside the individual limits. The total cap exists because the individual caps add up.
Where the heavy items hide
Three places, in the order I would look:
- Issue properties. Invisible in the UI, written by apps and scripts, and the one component where a runaway loop leaves no trace a user would see. Each property value is capped at 32 KB by the REST API, but nothing caps how many properties an item carries. Credit to @Nicolás De León (Vortex Labs) for the triage question that matters: for each vendor prefix in Get issue property keys, is the data written once and overwritten (stays small), or appended on every event with a counter, a date or a run ID in the key (grows until November)? Forge hosted storage, by contrast, is scoped to the app installation and does not count toward the item.
- Comments from integrations. CI bots, monitoring hooks and automation rules that append a payload on every event. A “status” comment every ten minutes for three years is 150,000 comments’ worth of attempts; the 5,000 cap will have stopped the count, but not before each one carried a log excerpt.
- Plain text custom fields used as log sinks. Someone made a 25 MB text field the place a script dumps its output.
Interactive users almost never get there. Service accounts do.
Measuring an item: the method, credited
On my discussion thread about this, @Becker_ Rene proposed the simplest useful approach : pull each work item through the API with everything expanded and measure the size of the JSON. It is a proxy, not Atlassian’s internal storage figure, but it is a proxy that ranks items correctly, and ranking is what you need. Three things to get right, straight from the current REST v3 specs:
1. Ask for everything, because the default is not everything. Get issue returns all fields by default, but issue properties only when you ask (properties=*all) and history only when you ask (expand=changelog):
GET /rest/api/3/issue/{key}?fields=*all&properties=*all&expand=changelog
2. The inline blocks are pages, not totals. The changelog that comes back inside that call is a page with startAt, maxResults and total. If total is bigger than what you received, the item has more history than you measured; page it through Get changelogs (100 per page by default). Do the same check for comments and worklogs: Get comments returns total with a default page of 100; Get issue worklogs returns total with a default page of 5,000. For a first pass you do not need the bodies at all. The three total values are a cheap heaviness score on their own.
3. Properties deserve their own look. Get issue property keys lists what is attached; an item with dozens of keys from one app prefix is a lead before you measure a byte.
Do not scan the whole site
Measure a shortlist. Build it with enhanced search (/rest/api/3/search/jql), which returns IDs only by default, pages with nextPageToken, and allows up to 5,000 per page when you ask for IDs alone. The JQL has to be bounded. Candidates that have earned a place on the list:
- Items in the projects your integrations write to, created more than two years ago.
- Items last updated by a service account rather than a person.
- Anything still open in a project that has had a CI or monitoring integration for a long time.
- Items that came across in a Data Center to Cloud migration carrying multi-year history. The announcement singles these out.
Then run the three-total check from step 2 against the shortlist, sort descending, and pull the full JSON only for the top of the list. On a normal site the top item is a few megabytes and you are done. If the top item is tens of megabytes or more, you have found the integration to fix before November, not after.
What to do with what you find
- An integration writing to one item forever: change the design. One item per run, per day or per deployment, linked back to the parent. The announcement says it plainly: do not use a single work item as a perpetual data dump.
- Runaway properties from an app: check the vendor’s cleanup guidance before deleting anything; properties can be the app’s state.
- A migrated item with enormous history: nothing to fix today; the November cleanup is non-destructive and comments become a downloadable zip. Know which items they are so the zip does not surprise the team that owns them.
- A business-critical item already over the line: Atlassian Support, with the key, before November.
Checklist
- List the service accounts and automation rules that comment on or update work items.
- Build a bounded JQL shortlist from their projects; pull IDs through
/rest/api/3/search/jql. - For each ID, read the
total from Get comments, Get issue worklogs and the changelog page; sort. - For the top of the list, pull the full item with
fields=*all&properties=*all&expand=changelog and measure the JSON, paging anything whose total exceeds its page. - Fix the writer, not the item.
Update, 25 October: I asked Atlassian on the announcement thread for a way to see a work item’s current size and for a warning threshold below 500 MB. Snehal Shah (Atlassian) answered on 23 October: no pre-warnings, UI size display or size-check API are planned for now; usage will be tracked and they may be added if needed. Work items migrated from Data Center above the limit get the same non-destructive cleanup as oversized Cloud items (historical comments, except those with custom permissions, compressed into a zip attachment; the item becomes editable again). The limit applies across Jira, Jira Service Management and Jira Product Discovery. So the method above is the way to find your candidates: nothing in the product will warn you first.
Thanks to @Becker_ Rene for the method on the thread . I have not run this at scale on a production site; the size you measure is a proxy for ranking, not Atlassian’s number. Corrections welcome below and I will fold them in with credit.
Verified 18 October 2026, updated 25 October 2026 from Snehal Shah’s answer, against the Jira Cloud announcement.
Updated 20 October with the property-size cap and the overwrite-versus-append test, credited to Nicolás De León.
