Every Microsoft Teams channel creates a document library in SharePoint Online. Most organisations running Teams have hundreds of these libraries and no real picture of how much storage they collectively hold.
When the SharePoint storage gauge starts climbing and nobody can explain why, Teams is usually the answer. The connection between Teams activity and SharePoint consumption is real and direct, but the admin tooling makes it easy to miss. This post breaks down the five most common ways Teams files accumulate in SharePoint storage and what you can actually do about each one.
Why Teams Files Live in SharePoint
When a user attaches a file to a Teams channel conversation, or accesses the Files tab in a Teams channel, they are working in a SharePoint document library. Microsoft Teams does not have its own file storage backend. Every team maps to a Microsoft 365 Group, and every Microsoft 365 Group gets a SharePoint team site. Each channel in that team gets a folder inside the site's default document library, plus Private Channels get their own separate SharePoint sites entirely.
This architecture is transparent to end users, which is by design. But it means that every file activity in Teams is a file activity in SharePoint, and every gigabyte consumed by Teams files counts against your Microsoft 365 tenant storage quota.
5 Ways Teams Channel Files Drain Your Storage Quota
1 Channel attachments accumulate invisibly with every conversation
When a user attaches a file to a Teams channel message, the file is uploaded to SharePoint. This happens even if the user intended only to share it temporarily for that conversation. There is no automatic expiry. The file sits in SharePoint indefinitely unless someone actively deletes it.
In active channels with years of history, the attachment folder can hold thousands of files. Many of these are duplicates: the same contract PDF attached in three different conversations because people do not think to link to the existing file. Each copy is a separate file consuming separate storage.
This is the highest-volume driver for most organisations. A busy channel over three years can accumulate 10-20 GB of attachments without anyone being aware of it, because the Files tab only shows the top-level folder structure, not the full storage breakdown.
2 Meeting recordings are stored at scale
Teams meeting recordings are video files. A one-hour recording in HD is typically 1-2 GB. When Microsoft moved meeting recording storage from Microsoft Stream (classic) to SharePoint and OneDrive for Business, this shifted a large category of large files into the same storage pool as documents and attachments.
Channel meeting recordings land in the SharePoint document library of the channel where the meeting was hosted. This means recordings from channel meetings count against the SharePoint team site quota, while ad-hoc meeting recordings land in the organiser's OneDrive.
"We found 60 GB of Teams recordings from meetings held more than eighteen months ago, stored in SharePoint sites for teams that had been archived for over a year. None of it was visible from the standard SharePoint storage report." - SharePoint admin at a 500-person professional services firm
Most organisations have no policy about recording retention. Meetings are recorded, they sit in SharePoint, and storage grows. Cleaning this up manually is impractical at scale; the recordings need to be found, assessed for value, and deleted in bulk.
3 Abandoned teams keep their SharePoint sites running
Teams get created for projects, onboarding cohorts, event planning, short-term working groups, and dozens of other temporary purposes. When the project ends, the team is often just abandoned rather than archived or deleted. Members stop using it. The last activity date moves further and further into the past. And the underlying SharePoint site continues to exist, holding all the files from the project period.
Microsoft does not automatically delete abandoned Teams or their SharePoint sites. The Microsoft 365 Group expiry policy can be configured to prompt owners to renew or delete idle groups, but this requires configuration and depends on owners responding to the renewal prompts. In practice, many tenants have dozens of abandoned teams with SharePoint sites holding content nobody has accessed in years.
The storage from these sites adds up, but it does not appear obviously in most storage reports because each site is small on its own. The aggregate across fifty abandoned sites can be significant.
4 File duplication from re-attaching documents across channels
Teams users rarely know to link to existing SharePoint files. The more common behaviour is to download a file from one channel conversation, then upload it again in a different channel or a different team. Every upload creates a new copy. Version history on the second copy starts from scratch.
This pattern is more common than it might appear. Status updates, reports, briefing documents, and templates get circulated this way across multiple teams and channels. By the end of a project, the same core document might exist as six separate copies across four different SharePoint document libraries, each with its own version history.
This is a behaviour problem, not a platform problem. The platform supports linking to existing files from Teams. The fix is partly cultural (encouraging linking over re-uploading) and partly operational (periodically identifying duplicate files and removing the redundant copies).
5 Version history on Teams files is rarely managed
Every document library in SharePoint Online has version history enabled by default. By default, major versions are kept with no limit. In a busy Teams channel where a shared document is updated frequently, hundreds of versions can accumulate over the life of a project.
Version history storage is not visible to users browsing the Files tab - there is no dedicated size column or storage indicator in the Files view. A 500 KB document through 200 versions might be consuming 40-80 MB depending on how much each version changed. Across a typical Teams environment, that background storage adds up to a meaningful share of total consumption.
Unlike the attachment accumulation problem, this one has a direct solution: trimming old versions. ShareMaster's Version Trimmer (part of Space Master) identifies libraries with excessive version history and lets you set a sensible limit across an entire site, removing older versions in bulk.
Explore Space Master storage toolsWhat the SharePoint Admin Centre Storage Report Shows (and Misses)
The SharePoint admin centre provides a storage report that shows used and allocated storage per site. This is useful for identifying the largest sites, but it has two gaps that matter for Teams-driven storage.
First, Private Channel sites do not always appear prominently. Each private channel creates its own SharePoint site, and these sites can be named in ways that make them hard to connect back to the parent team without additional investigation. A report showing 200 sites may include 40 private channel sites that are not immediately recognisable as such.
Second, the storage figure for each site includes version history storage but does not break it out. You cannot tell from the admin centre report alone how much of a site's 8 GB is current files, how much is file attachments from channel conversations, and how much is version history. That level of detail requires either drilling into each library or using a tool that exports a library-by-library breakdown.
ShareMaster's Report Master can export a storage breakdown by library and document type, giving you the information you need to decide where to clean up rather than guessing.
Finding and Reducing Teams-Driven SharePoint Storage
The practical sequence for addressing Teams-related storage growth:
- Identify which SharePoint sites belong to Teams. Every team-connected site has a Microsoft 365 Group attached. You can filter by group-connected sites in the SharePoint admin centre. Private channel sites follow a naming convention (the parent team name plus "- [channel name]") that makes them identifiable once you know the pattern.
- Find abandoned sites. Sort by last activity date. Sites with no activity in 12+ months from teams that no longer have active members are candidates for archiving or deletion. Verify with the group owner (if reachable) before deleting anything.
- Trim version history at the library level. For active Teams sites, set a maximum version count for each document library. A limit of 50 major versions is usually sufficient for any real operational need and prevents unbounded accumulation.
- Identify and delete large recording files. Meeting recordings are easy to find because they are video files (MP4) with distinctive naming patterns. A library-level file type and size report makes them easy to locate and assess.
- Remove duplicate files. This is the hardest step to automate, but identifying files with identical names across multiple libraries is a reasonable proxy for finding re-uploaded duplicates. ShareMaster's storage reduction guide covers the approach in detail.
None of these steps requires extensive scripting. The barrier is mostly visibility: standard tooling does not surface the problem clearly enough for admins to prioritise it. Once you have a clear per-library breakdown, the cleanup decisions are usually straightforward.
Teams file storage growth is a structural feature of how Microsoft 365 works, not a configuration problem. It will continue accumulating as long as people use Teams. The answer is not to fight the architecture but to build a periodic cleanup routine into your tenant management cadence, the same way you would manage email storage or version history on any other document management system.