Applies to: Jira Cloud
Audience: App developers, integrators, automation owners, and teams operating automated systems or planning large migrations. Customers using Jira interactively for day-to-day work are highly unlikely to be affected.
Summary
Starting in November 2026, Jira Cloud is introducing a total work item size limit of 500 MB per work item (Excluding file attachments). This limit supplements existing per-work-item limits and field-level size caps described in Work item field limits in Jira Cloud | Jira and Jira Service Management | Atlassian Support.
The total work item size limit acts as a platform safeguard designed to protect system reliability, responsiveness, and storage health across Jira Cloud.
Why is this limit needed?
As Jira Cloud scales to support millions of teams worldwide, safeguarding core system reliability, infrastructure stability, and service resilience requires proactive limits against extreme data anomalies. Introducing a 500 MB total limit provides essential reliability safeguards across the platform:
Why is a total work item limit needed when individual field limits already exist? Individual entity and field limits in Jira are intentionally set very generously to accommodate the diverse ways different customers use the product.
A total combined work item size limit provides an essential holistic platform safeguard, preventing a combination of multiple large fields from collectively creating a pathological data footprint that jeopardizes system stability.
- Protects system stability: Extremely large work items; often created by automated scripts uploading large logs or data dumps; can use up excessive shared resources and impact overall service health.
- Ensures dependable service uptime: Capping total work item size prevents sudden slowdowns and service interruptions, keeping Jira reliable and responsive for all functionality.
- Keeps search and background tasks fast: Search indexing, notifications, and background updates continue running smoothly without getting delayed by oversized items.
- Prevents app and integration errors: Setting clear size limits protects connected apps, automations, and custom scripts from unexpected timeouts and sync failures.
The limit at a glance
For context: how large is 500 MB? In plain text and metadata, 500 MB is roughly 500 million characters, approximately 80 to 100 million words.
To put that into perspective, the entire 20-volume printed Oxford English Dictionary contains roughly 60 million words.
A single 500 MB work item could hold more text than the entire Oxford English Dictionary plus several multi-volume encyclopedias combined.
Because typical Jira work items range from a few kilobytes to a few megabytes, an item would have to accumulate tens of thousands of times more data than normal to approach this limit.
What is included and excluded in the 500 MB limit
Included in the 500 MB calculation:
The total combined work item size encompasses all structured metadata, text fields, and relational content associated with the work item, example inclusions:
- Comments and Worklogs: All comment entries and logged work details.
- Descriptions and standard fields: Like Summary, description, environment, status, priority, resolution.
- Custom fields: Plain text, URL, numeric, select, and rich-text custom fields.
- Issue properties: Custom app data and plugin metadata attached directly to the issue.
- Links & relations: Remote issue links, issue-to-issue links, and web links.
- People & notification lists: Voters and watchers data.
- Other system & module data: Sprint details, SLA tracking data, approvals, and history metadata.
Excluded from the 500 MB calculation:
- File attachments: The actual binary file sizes of uploaded attachments (such as PDFs, images, videos, zip archives) are excluded from this 500 MB calculation. Attachments remain governed by their own individual attachment size limits.
When this limit may be encountered
In order of increasing likelihood:
1. Everyday interactive use
Creating work items, commenting, updating descriptions, logging work, and collaborating manually will not approach this limit. For standard interactive use, this limit is completely invisible.
2. Apps, integrations, and automation
Automated processes, Marketplace apps, CI/CD integration bots, or custom REST API scripts that continually append unstructured data, machine logs, or extensive payloads to a single work item over time can accumulate excessive size. We recommend designing business processes and automation to avoid using single work items as perpetual data dumps.
3. Migrations
Large data imports and Data Center to Cloud migrations carrying extensive multi-year histories on single issues may occasionally encounter oversized items. Jira Cloud tooling assists in identifying and resolving oversized content during migration.
What happens when the limit is exceeded
- New additions are rejected: If an update or creation would cause the total work item size to exceed 500 MB, the write operation is rejected and the new content is not saved.
- API feedback: API calls will return a
413 Payload Too Large error indicating the size limit has been exceeded. - One-time transformation for existing oversized work items: For the handful of existing work items currently over the 500 MB threshold, Jira is performing a non-destructive one-time cleanup transformation. Comments (excluding those with custom permissions) are safely compressed into an archive zip file and attached directly to the work item. No data is deleted, all content remains accessible, and the work item remains editable for new comments provided subsequent updates do not breach limits.
How to resolve an oversized work item
- Identify heavy components: Check for extensive comment histories, runaway issue properties created by apps, or very large custom field payloads.
- Reduce or split content: Clean up unnecessary historical comments/worklogs, trim bulky field text, or split continuous streams of work across multiple linked work items.
- Contact Atlassian Support: If you encounter a block during migration or on a business-critical work item, contact Atlassian Support for guidance.
Frequently Asked Questions (FAQ)
Why is this total limit being introduced?
To safeguard core platform reliability, prevent system degradation caused by extreme data anomalies, and protect shared infrastructure, background event queues, and API responsiveness across Jira Cloud.
Do attachments count towards the 500 MB limit?
No. Binary attachment files are stored separately in dedicated media storage and do not count toward the 500 MB work item limit.
Will this delete any of my existing Jira data?
No. For the tiny fraction of existing work items that already exceed the 500 MB threshold, Jira performs a non-destructive cleanup transformation: historical comments (excluding those with custom permissions) are safely compressed into a zip archive (e.g., comments.zip) and attached directly to the work item. This ensures zero data loss, preserves all comment history as a downloadable attachment, and restores the work item so teams can continue editing and adding new comments. For all other work items, existing data is untouched, and the limit applies strictly to incoming write/update operations.
Does this replace existing field-level limits?
No. Existing limits, such as the 1 MB rich-text entry cap, the 25 MB per unbounded field cap, and the 50,000 voter/watcher caps, remain in place and work alongside this total limit.
Where can I find full documentation on Jira Cloud limits?
Consult the official Knowledge Base article at Work item field limits in Jira Cloud | Jira and Jira Service Management | Atlassian Support.
