Manage Site Storage Limits in SharePoint in Microsoft 365: Everything You Need to Know

SharePoint site storage isn’t unlimited, and left unmanaged it grows quietly until someone hits a quota wall mid-project. Here’s how to actually keep it under control.

In this post: How the storage pool actually works · What counts against your quota · What actually happens at the wall · Checking and setting quotas with PowerShell · Archiving instead of deleting to free up quota · Best practices · When would you actually use this? · Related reading

How the storage pool actually works

Your tenant’s total SharePoint storage is 1TB base, plus 10GB per eligible license, plus any Extra File Storage add-ons purchased. That’s a shared pool — by default, SharePoint draws from it automatically per site, so you’re not manually dividing storage between sites site-by-site. If you’d previously set manual per-site limits and switch to pooled storage, existing limits reset to 25TB per site, even though your organization’s real total is almost certainly far less than that — worth knowing so a 25TB-looking quota doesn’t make you think you have more room than you do.

What actually counts against your quota

This is the part that trips people up during a cleanup. The first-stage recycle bin (items a user deletes) still counts against the site’s storage — deleting a file doesn’t free up space until it’s purged from both recycle-bin stages. The second-stage recycle bin (the site-collection-level bin admins see) generally does not count against the quota, with one exception: deleted subsites go straight to the second-stage bin and keep counting until they’re purged from there too. That second-stage bin itself is capped at 200% of the site’s quota — if deleted content exceeds that, SharePoint starts auto-purging the oldest items to make room, whether anyone asked it to or not.

Practical takeaway: if a site is near its quota and a bulk delete didn’t recover the space you expected, check both recycle bin stages before assuming something’s wrong — via Site Settings > Recycle Bin and (for the second stage) the SharePoint admin center’s recycle bin view for that site.

What actually happens at the wall

The intro above mentions someone “hitting a quota wall mid-project” — worth being concrete about what that actually looks like, since it’s less catastrophic than it sounds but still a real disruption. A site that exceeds its quota goes read-only, not offline: existing content stays fully viewable and downloadable, but new uploads, edits, and saves all get rejected, typically with a message like “Site quota is full” or a banner saying the organization’s storage is full. Nothing gets deleted automatically to make room — the lockout is the enforcement mechanism, not data loss.

Getting out of it needs one of three things: an admin raises that site’s quota (assuming there’s headroom left in the shared tenant pool), someone frees up space by deleting content (and actually purging both recycle bin stages, per the section above), or the tenant adds capacity via more licenses or a storage add-on. None of these happen automatically — which is exactly why the scheduled 80%-threshold check in the PowerShell section below is worth having before a site hits this state mid-upload, rather than finding out from a locked-out user.

Checking and setting quotas with PowerShell

The admin center works fine for a one-off check, but PowerShell is the practical route once you’re managing more than a handful of sites:

Connect-SPOService -Url https://contoso-admin.sharepoint.com

# Check current usage and quota for one site
Get-SPOSite -Identity https://contoso.sharepoint.com/sites/ProjectX | Select-Object StorageUsageCurrent, StorageQuota

# Set a manual quota (in MB) for one site
Set-SPOSite -Identity https://contoso.sharepoint.com/sites/ProjectX -StorageQuota 512000

# List every site over 80% of its quota, tenant-wide
Get-SPOSite -Limit All | Where-Object { $_.StorageUsageCurrent -gt ($_.StorageQuota * 0.8) } |
    Select-Object Url, StorageUsageCurrent, StorageQuota

That last command is the one worth scheduling — run it monthly (or wire it into a Power Automate flow with an email step) and you catch sites approaching their limit before someone hits a hard wall mid-upload, instead of finding out from a support ticket.

Archiving instead of deleting to free up quota

Raising the quota (more license/add-on cost) or deleting content (not always an option someone’s willing to sign off on) aren’t the only two ways out of the wall covered above — Microsoft’s native site-level archiving is a genuine third path worth knowing specifically because it doesn’t require either. Archiving a site moves it entirely out of active SharePoint storage into a separate, cheaper cold-storage tier — roughly $0.05/GB per month against active storage’s ~$0.20/GB, a real 75% reduction — while keeping the content intact and restorable, just not counted against this quota anymore.

Connect-SPOService -Url https://contoso-admin.sharepoint.com
Set-SPOSiteArchiveState -Identity https://contoso.sharepoint.com/sites/OldProject -ArchiveState Archived

The real value here is specifically for the sites this post’s audit script above tends to surface: something old, rarely touched, but not clearly safe to delete outright — exactly where archiving beats both alternatives. Reactivating is free and near-instant within 7 days; the tradeoff is that the archived site is genuinely cold while it sits there, invisible to search and browsing, not just read-only the way an over-quota site is. That makes it the wrong fit for anything still occasionally needed, and the right fit for anything the storage-audit report keeps flagging month after month with nobody actually opening it.

Best practices

Set quotas by site type, not one blanket number — project sites with large document libraries need more headroom than a standard team site. Use auto-growth selectively: enable it for sites that genuinely can’t afford disruption, not everything by default.
Monitor and audit regularly via Microsoft 365 Admin Center > Reports > Storage, or automate it with a PowerShell script so you’re not relying on someone remembering to check.
Control versioning, don’t just enable it — unlimited version history quietly consumes storage. Cap retained versions (10-20 is a reasonable starting point) or set a cleanup policy.

Versioning helps with content recovery, but unlimited version history quietly consumes storage — cap it, don’t just enable it and forget.

When would you actually use this?

A team hit their storage quota mid-project and you need to know why — versioning left uncapped is a common, invisible cause worth checking first.
You’re provisioning new project sites and want quotas that match actual expected use, not a guess.
Storage costs are climbing and nobody’s looked at which sites are actually driving it — a scheduled audit report answers this instead of guessing.

OneDrive Cloud and Sync Limitations — OneDrive draws from the same tenant storage pool this post covers.
O365 SharePoint Online and File Sync Limitations — sync limits that matter once storage starts filling up.

Hope that clears things up. Feel free to drop a comment if you need more detail.