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 · Checking and setting quotas with PowerShell · Best practices · When would you actually use this?


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.


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.


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.

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


App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning

Leave a Comment

Your email address will not be published. Required fields are marked *