nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

A 500 MB limit per work item arrives in November. How are you finding the ones that will hit it?

Sami Shaik

Atlassian published the number this morning (Snehal Shah, Atlassian Team, Jira Cloud - Total Work item size limit (500 MB)): from November 2026, any write that would take a work item past 500 MB of combined data (comments, worklogs, links, properties, voters, watchers, every field; attachments excluded) is rejected, the API returns 413, and the handful of items already over the line get their comments zipped into an attachment. The KB Work item field limits in Jira Cloud now lists it alongside the per-item counts: 5,000 comments, 10,000 worklogs, 2,000 attachments, 2,000 links, 50,000 watchers and voters, 25 MB per unbounded field, 1 MB per rich-text entry.

Atlassian is right that an interactive user will never get near it. The items that will are the ones no human reads: the monitoring ticket a bot has commented on since 2021, the CI integration that posts every build log to the same “pipeline health” item, the alert deduplication target, the app that writes issue properties on every sync. I know those items exist on every large site. What I do not have is a way to find them, and that is the question.

What I have ruled out so far:

JQL. There is no size function, and no field for comment count, worklog count or property size. You can find items with many comments only indirectly, and not by size at all.
The REST search API. You can page through candidates and count comments or worklogs per item, but that is one call per item at scale, and it still does not measure properties or history.
Automation. Rules can read field values, not an item’s storage footprint.
The KB and the announcement describe what counts; neither names a report, a field or an endpoint that exposes the total.

So, three questions for admins who run large or old sites:

How are you planning to find the at-risk items before November: a proxy query on comment counts, an audit of the accounts that comment most, something from Analytics or the Data Lake, or waiting for the first 413?
Has anyone found an Atlassian-provided way to read a work item’s current size that I have missed?
For the known offenders (the perpetual bot tickets), are you splitting them by period now, or letting Atlassian’s zip-and-attach cleanup handle it in November?

If a reliable method comes out of this thread I will write it up with credit. Verified against the Atlassian announcement and the KB on 13 October 2026.

Links:

https://community.atlassian.com/forums/discussion/3312916/jira-cloud-total-work-item-size-limit-500-mb

Comments

Becker, Rene

Since attachments don't count, I think it will be hard to meet the ceiling.

To be sure though, my approach would be to just use a script (PowerShell or similar) to fetch work items via API, include full extensions and then get the size of the JSON. If it it approximates close to 500MB, take action.

It's theory because, I haven't tested nor needed to do that. But If you run the risk, it might be a simple fix.

Sami Shaik

@Becker_ Rene , thank you, that is the first practical method on the thread and it is close to what I would do. Measuring the serialised JSON is a decent proxy for the text-and-metadata footprint, since that is roughly what the limit counts. Three refinements, based on the Get issue reference:

Ask for the things a plain GET leaves out. Issue properties are returned only when you pass properties=*all, and app-stored payloads are one of the two inclusions Atlassian names as risky. History comes back only with expand=changelog, and it arrives as a page (maxResults, startAt, total), so the first response is not the full history on a long-lived item. Without both, the JSON size understates precisely the items you are looking for.
Check the comment and worklog blocks against their totals. Before trusting one GET per item, compare the number of comments in the response with total from GET /issue/{key}/comment?maxResults=1, and the same for worklogs. If the single GET returns fewer than the total, the body is paged and the size needs the remaining pages added. On the bot-fed tickets that matter here, that is the common case.
Agreed on the ceiling. With attachments excluded, an interactive ticket will not get near 500 MB. The candidates are machine-written: a long-lived item that a CI bot, a monitoring integration or an app sync has been appending to for years. So I would run your script only against a shortlist (old items still being updated, by service accounts) rather than the whole site.

With those three, your approach becomes: shortlist, GET with properties and changelog, add the extra comment and worklog pages, measure. If you run it, the shape of the top ten would be worth posting back; I suspect it is two or three accounts behind most of them.

Becker, Rene

I didn't know that there was inline paging. I thought expansion would suffice. That's a good takeaway for me :-)

Thank you for the elaboration.

Sami Shaik

Update: I have written the method up as an article, with @Becker_ Rene ’s JSON-size approach as the core and the paging and totals checks from the current REST v3 specs around it: Jira’s 500 MB per work item limit arrives in November: find the ones that will hit it first. Still interested in anyone’s real top figure from a production site; the article says plainly that I have not run it at scale.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

rest-api

jira-cloud

jira-administration

jira-automation

limits