[CANCELED] Storage warning demands 0.3 GB deletion — but only 217 MB of attachments exist (via API).

Question

We received the standard "Action required" storage warning for our Confluence Free instance, stating we need to delete 0.3 GB of files by May 28, 2026 — or upgrade.

Before considering an upgrade, I ran a full inventory of all spaces using the Confluence REST API. TOTAL (API-visible) ~217 MB

The Confluence Free plan allows 2 GB. If only 217 MB are visible, why is the storage limit nearly reached?

What the API cannot see

After some research, I suspect the delta is caused by storage that is not exposed via the standard API:

* Page revision history — 665 historical versions across 108 pages. These are never returned by the attachment API.
* Thumbnails generated per page version
* App-specific storage — draw.io and similar macros store data outside the attachment model
* Macro storage (inline content, editor drafts)

The core problem

Atlassian is asking me to "delete files" to free up storage — but the files I can see and delete amount to only 217 MB. The dominant storage consumers (page history, thumbnails, app data) are not surfaced in the UI in any actionable way.

Deleting page history at scale requires either:

* Navigating to each page individually (Space Settings → Obsolete Content → Delete Versions), or
* Using the REST API in bulk — but there is no official endpoint for bulk version deletion on Free

Questions for the community / Atlassian

* Is there an official way to get a full storage breakdown (attachments + revisions + thumbnails + app data) without opening a support ticket?
* Is there a supported bulk API or UI workflow for purging page revision history across an entire site on Confluence Free?
* Why does the storage warning UI not show a breakdown of what is actually consuming the quota? Showing a single "delete files" CTA without surfacing revision history seems misleading.

Happy to share the full API inventory script if useful. Any pointers appreciated before I open a support ticket requesting a "storage breakdown" from Atlassian.

Karl Bauer · Answer

We wrote a script that deletes all previous page versions. Only the current versions are retained, and the other script continues to check (via the REST API) that the current versions no longer occupy any storage space.

The trash has also been emptied, and there are no archived sections.

As I mentioned in my other answer, we were constantly having problems because of the consistently incorrect VAT invoices (we used to have a payment plan, and we had to cancel it because of their constant billing errors). That’s why the finance department blocked them.

We just need to switch products faster, and that’s it.

Karl Bauer · Answer

For now, we’re switching to a different platform wherever possible.

Until recently, we were on a paid plan with our developers. But since the invoices were incorrect almost every month (VAT was charged even though we’re on a B2B reverse charge arrangement), it was an enormous hassle to get them corrected through support. After back-and-forth communication, they would eventually be corrected. They always blamed EU VIES, but we’ve been in business for 26 years—we’re not a startup whose data changes every three weeks.

We eventually canceled the service because, per company policy, the finance department blocks suppliers who are so uncooperative.

Kris Klima _K15t_ · Answer

Hi @Karl Bauer

Did you check the deleted/archived spaces/pages?

Deleted attachements also accumulate in the trash...