Jira Storage Limit: Uploads Blocked at 250 GB

On 29 October 2026 Atlassian started rolling out a change called Standard storage limit enforcement (that link opens Atlassian's change entry as raw data). Jira Standard sites have been getting storage warnings since at least 2023. What's new is the block: once a site reaches 100% of its 250 GB allowance, Jira blocks uploads until an admin deletes files or starts a 30-day Premium trial.

So if you're a Jira Standard admin, check your usage on the Storage page in Atlassian Administration this week and find the work items with the heaviest attachments. I'd only pay for Premium if you want its other features too. At 200 users it's about USD 19,620 a year more on monthly billing, and that's a lot of money for disk space.

If you searched for this before, you probably found the opposite advice. In May 2024 someone asked on the Community about storage limits for Jira (6,318 views when I checked on 10 November 2026) and wrote: "in the Jira admin portal, there is a statement that the storage limit is not being enforced." Atlassian staff said the same in at least five answers between 2018 and 2024, quoting Atlassian's own documentation at the time. That was true then. For Jira Standard it isn't any more.

We measured what we could on our own Jira Cloud test site. It's on Premium, so it can't show the new block screen, and we haven't seen it. Every number below says where it came from.

Seven things we found: only uploads are blocked, and there's no add-on

Each of these is argued further down, with its source.

1. Only uploads are named as blocked. At "100% usage" the change entry says to "delete files or start a 30-day Premium trial to unblock uploads". It doesn't say anything else stops working.
2. There's no storage add-on. Atlassian's storage doc says "the only way to increase your storage is to upgrade your plan".
3. The 250 GB is per app. Jira and Confluence each have their own allowance, and the change entry lists Jira (jira-software) only.
4. Most storage sits in very few places. On our site one space held 93.4% of 63.41 MB of attachments.
5. Jira's own top-ten list missed one. It skipped a business-space work item that our REST count ranked 8th.
6. Archiving a work item didn't free anything we could see. Archiving is Premium and Enterprise only, and on our Premium site the archived 100 MB test item stayed on Jira's storage list.
7. Premium is USD 5,940 to 19,620 a year more at 50 and 200 users on monthly billing.

What changed on 29 October: Jira Standard's 250 GB storage limit is being enforced

The change entry is short. It's marked "Rolling out" with a start date of 29 October 2026 and no end date, so your site may get it later than someone else's. The summary reads: "Jira Standard sites near or over the 250 GB storage allowance will see warnings and upload blocking in product and via email notifications. Admins can start a 30-day Premium trial, and non-admins can send a request asking an admin to upgrade, so teams have a path to keep uploads available."

For admins it says to watch for warnings "sent by email, Slack, or in-product when the site is near or over the 250 GB allowance", and "If storage reaches 100% usage, delete files or start a 30-day Premium trial to unblock uploads." For everyone else: "If a warning or block appears when uploading a file, request an upgrade from an admin."

It lists one product, jira-software. Jira Service Management (JSM) isn't named, so I wouldn't assume a JSM Standard site is in scope. JSM's Free plan got a different rule in September, and it's also still rolling out. Since 11 September 2026, Service Collection (Atlassian's bundle of JSM and Customer Service Management) "automatically starts a 14-day trial of the Standard plan for Free plan instances that exceed the 2 GB storage limit". On JSM Free the trial starts by itself. On Jira Standard an admin has to start it.

Atlassian's general storage doc, Track storage and move data across apps, says what happens at the limit: "We won't remove any of your data, but some actions in Jira and Confluence will become restricted until you upgrade or free up storage." It doesn't name the actions. The change entry names uploads, and that's the only one I can point you to.

What happens when Jira storage is full: warnings, then blocked uploads

I couldn't find the new warning or block wording in Atlassian's docs or on the Community as of 10 November 2026, and our Premium site can't trigger it. What admins pasted before still tells you what to look out for.

In 2023 a Jira Cloud customer quoted a banner reading "Your site is over the 250 GB storage limit". In May 2024 the asker in the storage-limits thread quoted an email: "Your Jira Software site has reached 90% of its 250 GB storage limit on your Jira Software Standard plan. Once you reach 100%, you will either need to clear storage space from your site or upgrade to Jira Software Premium for access to unlimited storage." That 90% comes from one customer's inbox in 2024. The change entry itself only says "near or over".

If you're not an admin and an upload fails with a storage message, the change entry says to request an upgrade from an admin. JSM has a Request a Premium trial flow, rolling out since the same day, that sends your billing admin a notification. Its entry lists only JSM, so I'm not certain the Jira storage block uses the same button.

Atlassian has done this on another plan before. In October 2023 it announced it would enforce the 2 GB limit on Confluence Free, and the cloud changes post said "you won't be able to create anything new in Confluence until you get more storage or upgrade". That was Confluence Free. Jira Standard's entry says upload blocking, and I wouldn't read the Confluence rule into it.

How to check Jira storage usage, and what counts toward the 250 GB

Before you start: you need to be a site admin. Atlassian's doc says "You must be a site admin to track storage." Everything below is Jira Cloud.

1. Go to Atlassian Administration and select your organization if you have more than one.
2. Open the site. If your admin home lists sites by name and URL (the original layout), select the site. If it has an Apps menu (the centralized layout), select Apps, then the site on the left.
3. Under Site settings, select Storage. Each app shows the storage used and, if it isn't unlimited, the amount left.

On our test site, in the screenshot above, each app has its own row. That matches Atlassian's file attachment doc: "The Standard plan allows up to 250 GB per app, and file storage is unlimited on Premium plans." Free is 2 GB per app. So Confluence Standard has its own 250 GB, and a big Confluence site doesn't eat into Jira's allowance. We searched all 1,086 entries in Atlassian's change feed and found no enforcement entry for Confluence Standard.

What counts? Atlassian's storage doc says "This storage is primarily used for attachments" and doesn't list anything else. No current doc I found says whether avatars, app data, trashed spaces or archived work items count. If your Storage page shows a number you can't explain, you're not alone. A request for more detail, JRACLOUD-75922, has 218 votes. It was raised in January 2021 and has been In Progress since September 2024.

Two other limits get mixed up with this one. A single file defaults to 1 GB and can go up to 2 GB (Settings > System > Advanced > Attachments). And new sign-ups get a 7-day trial of Standard or Premium, which is a different thing from the 30-day Premium trial in the storage change.

Find large attachments in Jira: Storage management and a REST script

Knowing you're at 240 GB doesn't tell you where it went, and Atlassian says so: "Currently, in Jira Cloud, Storage can be tracked per product but not per space." A space is what Atlassian used to call a project. There are two ways to find the heavy work items.

Jira's Storage management page lists ten work items, not always the top ten

You need to be a Jira admin for this page.

1. In Jira, select Settings (the gear), then Products.
2. Under Jira, select Storage management. A table lists 10 work items with their Total attachment size.
3. Select a work item to open it and remove the attachments you don't need. The page itself says: "To free up space, click on the work items and remove attachments, or upgrade for more storage".

On our site the page's sizes matched our REST count, rounded to decimal megabytes: WFH-152 holds 9,429,299 bytes and the page shows 9.43 MB. But the list wasn't complete. A work item in a business space (the kind Jira Work Management used to create) held 1,502,486 bytes, which our REST count ranked 8th, and it wasn't on the page at all. The page's 10th row was 1.19 MB. I don't know why. If your heavy files live in business spaces, don't rely on this page alone.

Atlassian's REST method gives you the full list per space (project)

Atlassian has a knowledge base article on finding total attachment size per project. It searches every work item with the JQL (Jira's search language) query attachments IS NOT EMPTY and adds up the size of each attachment. You need an API token for an account that can browse every space you want to measure and see its attachments. Admin rights alone don't guarantee that. The script pages through this request, 100 work items at a time:

curl -s -u "[email protected]:$JIRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -X POST "https://your-site.atlassian.net/rest/api/3/search/jql" \
  -d '{"jql":"attachments IS NOT EMPTY","maxResults":100,"fields":["project","attachment"]}'

Each work item in the answer carries fields.attachment, a list with a size in bytes per file. Add them up per fields.project.key, and pass the nextPageToken from each answer into the next request until isLast is true. Our script did exactly that and wrote out per-space totals plus the ten largest files. If you go on to download the files themselves, the content endpoint answers with a redirect, which we wrote up here.

So 1 work item in about 95 had an attachment, and one space held almost all of it. The largest file was a 9.30 MB screen recording. Three of the ten largest files were screen recordings, all from 2023, and the rest were PDFs, a zip and PNG images. Your site will have its own mix, so run the count before you decide what to delete.

The admin Storage page said 62.0 MB for Jira while REST added up to 63.41 MB. The software spaces alone came to 61.90 MB, which is closer, but no Atlassian source explains the gap, so I can't tell you whether business spaces count the same way.

The REST method also has a blind spot. Atlassian's trash doc says work items in a trashed space "won't appear in basic or advanced search results", so a JQL scan can't see their attachments. We couldn't check whether trashed spaces still count toward storage: our nine trashed spaces gave nothing back over REST, and we had nothing to compare them with. Archived work items drop out of search too, while Jira's Storage management page kept listing our archived one at 100 MB.

How to bulk delete attachments in Jira Cloud

Deleting is the free exit, and it's permanent. Atlassian's doc says you can "back up the data of your apps before freeing up the storage space", so get a copy of anything you might need first. You've got two native options today, and a third is on the way.

Delete all attachments on one work item

Open the work item, find the Attachments section, select More actions (···), then Delete all. You need to be an admin to delete all attachments on a work item. Files pasted into fields or comments have to be removed one by one (Atlassian's steps).

Delete old attachments with an automation rule

Atlassian's knowledge base article builds the rule like this:

1. Go to Settings > System > Global Automation and create a rule.
2. Pick the Scheduled trigger and give it a JQL. Atlassian's example is attachments is not empty and updated < startOfDay("-7d").
3. Add the Delete Attachments action and set it to all attachments.
4. Select Turn on rule and give the rule a name. It runs on the schedule you set, and Run rule runs it once straight away.

Atlassian's own warning is worth repeating word for word: "once you remove the attachments, there is no backup file or anything you can do to retrieve them." Its article also suggests "a more restrictive JQL query initially". I'd start with one space and a much older date, for example project = ABC and attachments is not empty and updated < startOfDay("-730d"), and widen it once you've seen what it removed.

Bulk delete from the attachments panel is on the way

It's marked Coming soon, with no date. The change entry says "You can only bulk delete 25 attachments at once."

Trashing or archiving a space isn't a quick win

A trashed space keeps its work items and attachments for 60 days before Atlassian deletes them permanently, and we couldn't confirm whether they count during those 60 days. Archiving a space is Premium and Enterprise only, so on Standard you can't archive new spaces.

Archiving a work item didn't take it off the storage list

Archiving work items is only available on Premium and Enterprise. Atlassian's bulk archive article says "Archiving work items is available on Premium and Enterprise plans", so a Standard site can't archive work items. It matters if you're on a trial or already on Premium and wondering whether archiving old work frees storage, so we tested it on our Premium test site.

At 00:57 on 10 November 2026 (Bucharest time) we created a task, LZPT-615, and uploaded one file of exactly 100,000,000 bytes. When we first opened Jira's Storage management page, 21 minutes later, LZPT-615 was at the top with 100 MB. Then we archived it. A JQL search for its key found nothing after that, while the REST API still returned it by key.

Sixteen minutes after archiving, the Storage management page still listed LZPT-615 at 100 MB, as in the screenshot below, and a re-check at 28 minutes showed the same. The admin total couldn't tell us more. It said 62.0 MB right after the upload and still said 62.0 MB 54 minutes later, even though the page says changes may take up to 30 minutes. We archived at minute 21, so we can't tell whether that figure is slow or skips archived files.

So if you're cleaning up to get under a limit, delete attachments, and don't count on archiving work items to free anything.

After a cleanup, give the meter time. The admin page says changes may take up to 30 minutes for Jira, and on our Premium site the figure still hadn't moved 54 minutes after a 100 MB upload (we had archived that work item at minute 21, so part of that wait may be the archive, not the meter). In December 2025 a Jira Free admin reported the meter stuck at 2 GB after deleting attachments, and a Community Champion replied that updates can take a day or two.

Jira Standard vs Premium pricing: is cleanup cheaper than the upgrade?

Premium removes the limit, and there's nothing smaller to buy. The prices below are Atlassian's list prices in USD from its cloud pricing tables, effective 13 October 2026. Monthly billing is progressive: each of your first 100 users costs more than each user from 101 to 250.

What you'd actually pay on an upgrade depends on what you've already paid. Atlassian's own note says "Plan and user tier upgrade pricing depends on what you've previously paid."

A cleanup costs admin hours and no licence money. We haven't timed one on a real 250 GB site, so I won't put a number on it. But at 200 users, USD 19,620 a year buys a lot of afternoons spent deleting old screen recordings.

Premium does a lot more than storage, of course. If you already wanted its other features, the storage limit is one more reason, and our Premium vs Enterprise pricing at 200 to 500 users goes into those. If you're also budgeting for usage-based charges, our cost per user at 50 to 500 seats has the numbers.

What I'd do this week on a Jira Standard site

Open the admin Storage page and write down the Jira figure with the date. Take a second reading a few weeks later, and the difference tells you how fast you're growing and how often you need to look.

If you're close, open Jira's Storage management page, then run Atlassian's REST method, because the page only shows ten work items. Back up what you might need. Then clean up with a narrow automation rule.

And keep the 30-day Premium trial for when uploads are actually blocked and the cleanup can't finish in time. Once it starts, the clock runs.

Has your site already hit the new warning? If you've seen the wording, I'd love to know what it says, because I haven't found it posted anywhere yet. You can find me on the Atlassian Community or reach us at leanzero.net.

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.