Why your Microsoft 365 tenant is running out of storage (and what you can do about it)

Microsoft 365 storage full? Your pool is 1 TB + 10 GB per user. Where the growth really comes from — versions, recordings, leavers — and how to reclaim it.

LogiSam · 5 October 2026 · 6 min read
LogiSam TSO cover image: Microsoft 365 storage — where it went

Nobody notices Microsoft 365 storage until the day somebody cannot save a file. Then it becomes everyone's problem at once, and the only option anyone can see is to buy more.

The reason it arrives as a surprise is structural. SharePoint storage is pooled across the whole organisation, growth is spread across thousands of sites nobody owns individually, and the admin centre reports a number rather than a trend. Here is where the space actually goes, and what you can do that is cheaper than a purchase order.

Your storage is pooled, and the pool is smaller than people assume

Microsoft gives a tenant 1 TB plus 10 GB per licensed user for SharePoint, according to the SharePoint limits service description. That is the whole organisation's allowance, not a per-site one.

Run the arithmetic for a 500-user tenant and it is less generous than it sounds: 1 TB + 5,000 GB, or roughly 5.9 TB for every team site, every Teams channel's files, every document library and every Microsoft 365 group in the business. A single site can grow to 25 TB on its own, so nothing stops one project archive consuming the entire organisation's allowance.

OneDrive sits beside that pool rather than inside it. Each licensed user gets 1 TB on Business Basic, Standard, Premium, E3 and E5 — expandable to 5 TB on E3 and E5 — per the OneDrive service description. Microsoft is explicit that "pooled storage limits still apply at the tenant level".

Where the growth actually comes from

In the tenants we scan, the same five things account for the overwhelming majority of unexpected growth. None of them are the files people think about.

Version history

Every save of an Office file in SharePoint or OneDrive creates a version, and versions consume storage exactly like the file does. A 40 MB slide deck edited two hundred times is not 40 MB on disk.

Microsoft now offers two ways to control this, documented on the version history limits page: an Automatic setting, which Microsoft recommends because it optimises version storage for you, and a Manual setting where you cap major versions, optionally with an expiry period. Libraries configured manually are frequently set to 500 major versions, which is a lot of copies of a file that changes every day.

The important nuance: documents under a retention policy or an eDiscovery hold ignore library version limits entirely. If you have broad retention in place, capping versions will not touch the content that is growing fastest.

Teams meeting recordings

Recordings land in OneDrive for a private meeting and in the channel's SharePoint site for a channel meeting. They are video, they are large, and almost nobody deletes them. A weekly all-hands recorded for two years is a storage line item that no one ever decided to create.

OneDrive accounts belonging to people who have left

When a user is deleted, their OneDrive is retained — by default for 30 days, configurable up to ten years — and it keeps occupying storage for the whole period. Microsoft covers the mechanics in OneDrive retention and deletion. Organisations that have raised that retention to a year or more for HR reasons, and have had any staff turnover, are carrying a meaningful amount of storage for people who no longer work there.

Duplicates

The same attachment saved by six people into six libraries is six copies. So is the "final" folder copied to a new site at the start of each project, and the departmental share that was lifted into SharePoint during a migration and then lifted again when the first attempt was abandoned.

The recycle bins

This one catches people out. Microsoft states it plainly in the same service description: the storage used by a site's recycle bin "is part of the organization's total storage limit". Deleting a large library does not reclaim anything until the first-stage and second-stage recycle bins are also emptied — which can take 93 days if you leave it to the default schedule.

Why the admin centre doesn't warn you in time

This is not a criticism of the native tooling. The Microsoft 365 admin centre and the SharePoint admin centre both report storage accurately, and the SharePoint admin centre's site storage view will show you the largest sites. They answer the question "how much am I using?" very well.

What they do not answer is "what is in there, and how much of it needs to exist?" There is no cross-workload view that puts SharePoint, OneDrive, Exchange and Teams side by side. There is no duplicate detection. There is no estimate of how much you would get back by capping versions. And the storage number is a snapshot, so a tenant growing 2% a month looks fine right up until the month it does not.

The consequence is predictable. Nobody looks at storage while it is a trend, and everybody looks at it the day it becomes an incident — at which point buying capacity is the only intervention fast enough. Microsoft is clear in the service description about what happens if you do nothing: a tenant operating above its limits is "at a risk of your environment being put into 'read-only' mode", with users unable to add or modify content until usage drops or capacity is bought.

What to do about it, in order

Reclaim work has a natural sequence, cheapest and safest first:

  1. Empty the recycle bins on your largest sites. It is reversible in the sense that you chose what was deleted, it needs no policy change, and on a tenant that has done any migration work it is often the single biggest same-day win.
  2. Deal with leavers' OneDrives. Decide what the retention period should actually be, move anything worth keeping to a team site, and let the rest go.
  3. Set version limits at the organisation level, then trim existing versions on the libraries that justify it. Microsoft provides both a version storage report and a trim job for exactly this.
  4. Put a lifecycle on Teams recordings so they expire on a schedule instead of accumulating indefinitely.
  5. Then look at duplicates and genuinely large files, which take judgement and are better done with a list in front of you.

Only after those five is buying storage the right answer — and by then you will know how much you actually need, which is usually a smaller number than the one you started with. We walk through that trade-off properly in should you buy more M365 storage or clean up?

Seeing the whole picture in an afternoon

The hard part is not knowing what to do. It is getting a defensible list of what is actually in the tenant without spending a fortnight in PowerShell.

That is the job Tenant Storage Optimisation does. It scans SharePoint, OneDrive, Exchange and Teams in one pass, runs a hash-based duplicate sweep, scans file versions with a reclaim estimate attached, lists your largest files, and returns scored recommendations you can hand to whoever is going to do the work. Exports are PDF and Excel, so the finance conversation and the engineering conversation can use the same document.

It asks only for read-only Microsoft Graph permissions and it cannot change anything in your tenant — which is usually the first question security asks. It runs in Azure UK South.

If you want the detail before you scan anything, the TSO team has written up what to do when you are running out of storage and why Teams recordings eat SharePoint quota. On this site, the hidden cost of Microsoft 365 storage covers what is lurking in a typical 1 TB, and the real cost of extra storage explains the bill if you do decide to buy.

Microsoft 365SharePointstorageM365Storage

Want to apply this in your tenant?

Book a free call with a LogiSam consultant — we will show you the quickest, safest way to do it on Microsoft 365.

LogiSam Assistant Guided help & instant answers

Answers come from this website. Privacy policy

↑↓ to navigate ↵ to open