Attachments pile up in Confluence silently: images removed from a page but not from storage, files sitting on pages that were archived or trashed years ago, giant uploads nobody remembers. Ask "how much of my Confluence storage is attachment waste, and where is it?" and Confluence has no answer, not per space and not site-wide. Detecting unused attachments (CONFCLOUD-16577) is one of the longest-standing storage-hygiene asks on the Confluence Cloud issue tracker, with 291 votes and no built-in report. If you own a storage budget, or your site is pressing against its plan's storage quota, that blind spot is the first thing standing between you and a cleanup.
Why Confluence cannot tell you this out of the box
- There is no site-wide attachment inventory. Confluence has no screen that lists every attachment across every space with its size, so you cannot sort by size or find the biggest files anywhere in the product.
- Deleting an image from a page does not delete the file. The attachment stays in storage, invisible on the page and still counting against your quota, and nothing flags it as unreferenced.
- Archived and trashed pages keep their attachments. A page trashed years ago still holds its files as dead weight, and no report surfaces them.
- Space-level views do not roll up. Even where you can see a page's attachments, there is no total of reclaimable storage per space or for the site, so "which spaces are wasting the most?" is unanswerable without tooling.
The DIY approach: walk the REST API and classify every file
Everything needed for the missing report is reachable through the Confluence Cloud v2 REST API. A script can build the inventory:
- Enumerate every space (
GET /wiki/api/v2/spaces), then every page in each space across all statuses: current, archived, and trashed. - List each page's attachments
(
GET /wiki/api/v2/pages/{id}/attachments) to capture file size, media type, and version. - Fetch each current page's storage-format body and check whether each attachment's filename or file ID appears in it. Not referenced → flag it unused. On an archived or trashed page → flag it orphaned. Over a size threshold → flag it large.
- Roll the flagged bytes up per space and site-wide, sort biggest-first, and export to CSV for review.
The catches are volume and honesty. A large site means tens of thousands of paginated API calls, so the script needs rate-limit handling, retries, and a way to resume mid-sweep, and it goes stale the day after it runs unless you schedule it. And a textual reference scan has a known blind spot: a file surfaced only through an attachments or gallery macro, or an include from another page, reads as unused even though viewers can reach it. Any classification like this is a review shortlist, not a delete list, which is why the deletion step should always be previewed, confirmed by a human, and recoverable.
A ready-made option: Attachment Cleanup for Confluence
Attachment Cleanup for Confluence is that pattern packaged. It sweeps every space daily and on demand, inventories every attachment on every page, flags each one as unused, orphaned, or large, and totals storage and reclaimable bytes per space and site-wide, biggest opportunities first. Spaces that could not be scanned completely are marked partial rather than padded with guesses, and the full inventory exports as audit-ready CSV in one click. The report itself is read-only, powered by three granular read scopes. Cleanup is opt-in: an admin ticks flagged attachments, previews the exact set in a dry run that changes nothing, then confirms. The confirmed delete is a soft delete that moves each file to its space Trash, where it stays recoverable; the app never permanently purges and never touches a used file. Pricing is free up to 10 users, then about $1 per user per month, billed by Atlassian.
Key facts
- Native site-wide attachment report: none in Confluence Cloud (CONFCLOUD-16577, 291 votes).
- Waste categories: unused (not referenced in the page's current body), orphaned (on an archived or trashed page), and large files worth a look.
- DIY route: the v2 REST API exposes spaces, pages, attachments, and page bodies; the work is pagination, retries, scheduling, and honest classification.
- Safe cleanup: treat any unused flag as a shortlist; preview first, confirm, and prefer a soft delete to the space Trash so every removal is recoverable.
Related reading: find orphaned Azure resources still costing you money.
Written by the team at Katabarwa Labs. We build small, single-purpose Azure tools that run entirely inside your own tenant. Questions: abaho@llmgraph.ai.