SharePoint upload blocked? What the storage quota alert actually means

The first sign is rarely a dashboard. It is a person in finance who cannot save a spreadsheet, and a sync icon that has been spinning for an hour.

Hitting the SharePoint storage quota is one of the few Microsoft 365 failures that degrades rather than stops. Different things break at different moments, some of them silently, and the error messages do not say "the tenant is full". Here is what actually happens, in what order, and what to do in the first hour.

What breaks, and in what order

Microsoft's SharePoint limits service description states the consequence directly: a tenant that continues to operate above its storage limits is "at a risk of your environment being put into 'read-only' mode", meaning "users may be unable to add or modify content until storage usage is reduced or additional capacity is purchased".

In practice the symptoms arrive roughly like this:

• Office saves fail. Word, Excel and PowerPoint report that the file cannot be saved to the server. Users often assume it is their connection and retry for a while before raising it.
• OneDrive sync stalls. The client shows an error on specific files rather than a clear quota message. Local edits keep working, which means people carry on believing their work is saved.
• Teams file uploads fail. Posting a file to a channel fails, because the channel's files live in the site that is out of room.
• Teams meeting recordings fail quietly. This is the worst one. The meeting happens, the recording is attempted, and the file never appears. Nobody finds out until somebody goes looking for it days later.
• Power Automate flows that write files start erroring, usually with a generic failure that takes a while to trace back to storage.

Note the pattern: the failures surface at the edge, in the applications, not in the admin centre. If you are triaging an incident on symptoms alone, storage will not be the first thing you suspect.

Check these first, in this order

1. SharePoint admin centre → Active sites. Add the Storage used column and sort descending. You are looking for both the total against your limit and any single site that has grown out of proportion. Microsoft documents the view in manage site storage limits.
2. Confirm the tenant allowance. It is 1 TB plus 10 GB per licensed user, plus any extra storage add-on you have already bought. Check the add-on, because a previous incident may have been solved with a purchase that is now also exhausted.
3. Check whether a single site is the problem. A site can reach 25 TB on its own. If one site is most of your consumption, the fix is local and fast rather than tenant-wide.
4. Check site-level quotas. If quota management is set to manual, an individual site can be capped well below the tenant's available space — in which case the tenant is not full at all and you are chasing the wrong problem.
5. Check the recycle bins. Site recycle bin contents count against the organisation's total. A library deleted last week has not freed anything yet.
6. Check for a recent migration or a sync loop. A re-run migration or a mis-scoped sync can add terabytes in days, and the growth curve will tell you immediately whether this is gradual or an event.

The three quickest reclaim actions

Once you know where the space is, these three give you the most room for the least risk. They are the ones to do while the incident is still open.

1. Empty the site collection recycle bins

Because recycle bin contents count against the tenant total, emptying them on your largest sites converts deleted content into available capacity immediately. Both stages need clearing — the second-stage bin holds items for the remainder of the 93-day cycle.

Do it on the largest sites first and check the storage figure after each one. This is the highest-yield action on any tenant that has run a migration, because the discarded first attempt is usually still sitting in a bin.

2. Deal with leavers' OneDrives

A deleted user's OneDrive is retained for 30 days by default and up to ten years if someone has configured it that way, as set out in OneDrive retention and deletion. Check what your retention is actually set to before assuming this is already handled.

The safe sequence: identify leaver OneDrives above a size threshold, hand the contents that matter to the relevant manager or move them to a team site, then release the rest. Do not shortcut the review step — this is the action most likely to delete something a legal hold wanted.

3. Cap version history, then trim what exists

Setting a version limit changes what happens from now on. It does not reclaim anything on its own, which is where most people stop and wonder why the number has not moved.

Microsoft's version history limits documentation covers both halves: set organisation-level limits (the Automatic setting is Microsoft's recommendation for optimised version storage; Manual lets you set a major-version count with an optional expiry), then run the version storage report on a site to see what trimming would actually recover, and queue the trim job.

Two things to know before you do: trimmed versions bypass the recycle bin and cannot be recovered, and content under a retention policy or eDiscovery hold ignores version limits entirely. Run the report first.

What not to do in the first hour

Buying storage during the incident is reasonable — it restores service and it is reversible at the next renewal. Buying storage instead of finding out what happened is how a tenant ends up paying for the same megabytes every year forever.

Equally, do not run a bulk deletion across sites you have not looked at. The recycle bins and the leaver accounts are safe because you can reason about them. A broad "delete anything older than X" sweep across live team sites is not, and it will cost you more in goodwill than the storage is worth.

Preventing the next one

The reason this becomes an incident is that storage is reported as a snapshot and consumed as a trend. A quarterly look at consumption, growth rate and the composition of what is stored turns a 2 a.m. problem into a line on an agenda.

Tenant Storage Optimisation gives you that composition in one read-only pass: SharePoint, OneDrive, Exchange and Teams together, a hash-based duplicate sweep, a file-versions scan with the reclaim estimate attached, your largest files ranked, and scored recommendations in priority order. PDF and Excel exports, read-only Microsoft Graph permissions, hosted in Azure UK South.

Further reading from the TSO team: why SharePoint libraries hoard versions and OneDrive after they leave. On this site: where your tenant's storage actually goes, what extra storage costs, and five SharePoint storage hogs your CFO hasn't heard about.