How to Set Up Storage Usage Reports and Capacity Alerts

The first decision is what storage event should interrupt the team. For media teams, “storage is getting full” is too vague to be useful. A SAN at 82% used during offline editorial is different from a camera original bucket growing 8 TB per day, a review platform generating extra proxy and streaming files, or a nearline NAS filling with old exports nobody owns. Good storage reporting separates those cases. Good alerting tells the right person early enough to move, archive, expand, or stop ingest before the system creates a production problem.

Start with the volumes that can stop work

Most post facilities and production teams have more than one kind of storage, even if people casually call all of it “the server.” Your team should tie capacity alerts to the job each volume performs. The common buckets are:

Online working storage: fast shared storage for editorial, color, VFX pulls, audio, conform, or active finishing.
Ingest staging storage: temporary or structured storage where camera cards, audio, dailies, screeners, or vendor deliveries first arrive.
Nearline storage: lower-cost local NAS, object storage, or tiered storage for media that may come back soon but isn't actively being edited from.
Archive storage: LTO, cold object storage, deep archive, or another long-term copy.
Cloud production storage: object buckets, review platform storage, cloud workspaces, or transfer destinations.
Application-generated storage: proxies, thumbnails, waveform caches, streaming derivatives, transcodes, and review copies.

These categories matter because the response is different. If online editorial storage crosses a critical threshold, editors may see dropped performance or blocked writes. If archive storage grows, you may need a purchasing or retention decision, but the edit probably doesn't stop today. If a review platform reports “usage” higher than uploaded bytes, the difference may be generated files such as playback derivatives, not a mystery user uploading extra masters.

Storage area	Main capacity risk	Useful signals	First response
Online working storage	Editors, colorists, or finishing systems lose performance or cannot write new media	Percent used, free space, client bandwidth, failed writes, growth rate	Move inactive media to nearline, expand allocation, or pause nonessential renders
Ingest staging storage	New camera cards, audio, dailies, or vendor deliveries cannot land safely	Daily ingest rate, transfer status, verified copy status, free space	Clear completed transfers, move verified media downstream, or add temporary landing space
Nearline storage	Old projects and exports crowd out material that may need to return soon	Age, last access, project owner, archive status, snapshots	Archive older media, apply retention rules, or assign cleanup ownership
Archive storage	Long-term retention exceeds planned media, tape, or cold storage budget	Archive volume, job status, failed archive jobs, storage class cost	Approve more archive media, revise retention, or confirm which projects can be removed
Cloud production storage	Cost, object count, replication, or lifecycle rules grow beyond plan	Bytes stored, object count, ingress, egress, failed requests, monthly spend	Apply lifecycle policy, confirm replication intent, or notify the production owner
Application-generated storage	Proxies, thumbnails, cache files, and review derivatives consume space invisibly	Derivative size, cache age, transcode jobs, platform usage reports	Prune generated media, adjust retention, or explain usage difference to stakeholders

Treat every storage area as having an owner, a reporting cadence, and an escalation path. If nobody owns the volume, alerts become noise.

Measure capacity, growth, activity, and errors

A capacity dashboard that only shows percent used is better than nothing, but it won't help you plan. You need at least four classes of signal. Capacity tells you how much is used, how much is available, and where the data lives. Cloud storage discovery tools often break this down by account, container, bucket, region, project, folder, or asset. On-prem shared storage tools usually show volume, workspace, file system, pool, or media pack usage. Growth tells you whether the current situation is stable. A volume at 70% used may be fine if it grows 200 GB per week, but it's a problem if it grows 8 TB per shoot day. Growth rate is the difference between “we should clean this up” and “we need to order new storage before episode three.” Activity tells you whether the data is still doing work. Transactions, ingress, egress, client bandwidth, last access time, and upload history help identify whether files are active, abandoned, or ready to move. This is especially important for expensive high-performance storage. Video media is dense, and leaving inactive content on the fastest storage wastes the tier that editors actually need. Errors tell you whether capacity pressure is already affecting the workflow. Failed writes, failed reads, permission failures, missing objects, network errors, and application-level transcode failures can all look like “storage problems” to the user. Logs give you the evidence to separate a full volume from a deleted object, a permissions issue, or a client connectivity problem. A useful report combines these signals instead of forcing the post supervisor to compare five unrelated screens.

Set thresholds by lead time

The classic alert pattern is warning at 80%, critical at 90%, emergency at 95%. That's a decent starting point for generic IT storage. Media workflows need thresholds based on how fast the volume fills and how long it takes to react. For each volume, estimate:

Average daily ingest or creation rate.
Peak daily ingest during shoot, turnovers, or finishing.
Time required to delete, move, archive, or expand capacity.
Minimum free space required for safe application behavior.
Whether performance degrades as the volume fills.
Whether storage is shared across multiple productions or dedicated to one show.

The alert should fire when there's still enough time to do the next real action. If a production can generate 12 TB per day and it takes three days to approve, ship, and install more storage, a warning at “10 TB free” is already late. A better model is to express thresholds in both percent and days remaining. For example, a 100 TB online editorial workspace might warn at 75% if the recent growth rate says there are fewer than seven days remaining. It might go critical when there are fewer than three days remaining, regardless of whether that happens at 81% or 92%.

Capacity alerts work best when fullness and time remaining are considered together.

For cloud object storage, the capacity limit may not be hard in the same way, but cost and lifecycle rules are still real constraints. There, thresholds can include monthly spend, storage class distribution, object count, replication backlog, or growth against production budget.

Build reports for the questions people actually ask

Storage usage reports should answer the recurring production questions without requiring an admin to dig through raw logs. The most useful recurring reports usually include:

Total used, free, and allocated by storage system.
Usage by production, project, workspace, bucket, folder, or department.
Daily and weekly growth rate.
Archive candidates by age, status, or last activity.
Forecast date for reaching warning and critical levels.

The takeaway is simple: capacity planning asks what is growing, who owns it, and when we run out of safe room. Post supervisors should be able to read the report without storage admin context. For technical directors, it should preserve enough detail to investigate. That often means a short production-facing summary plus a detailed export to CSV, workbook, or log analytics view. Cloud reports often give you built-in categories like capacity, activity, errors, configuration, and consumption. Use those categories, but reshape them around your workflow. A generic subscription-wide storage report is less useful than one scoped to the production accounts, buckets, or containers that post actually depends on.

Keep ingest and verification visible

Your team should keep capacity reporting connected to ingest health. The place where media enters the system is where storage mistakes become expensive. Camera original and production audio workflows should already rely on checksum-verified copies instead of simple Finder, Explorer, or basic command-line copy. The reason is practical because if someone erases a card before your team catches a missing or corrupt file, the storage report isn't going to save you. Your monitoring should show whether expected media arrived, whether the verified copy exists, and whether downstream storage has enough room for the next batch.

Ingest monitoring should connect media arrival, verified copies, and remaining destination space.

In many productions, the handoff from set to post runs through a DIT, loader, data manager, or assistant editor. That handoff needs visibility into both data integrity and capacity. If the DIT is filling shuttle drives, uploading to cloud storage, and creating a local safety copy, the assistant editor should know what is complete, what is still transferring, and what is safe to ingest into editorial storage. For original camera files and original production audio, the usual resilience target is some form of 3-2-1 strategy: three copies, on two types of media, with one geographically separate copy. Whether that's local RAID plus LTO plus cloud, or local storage plus cross-region cloud replication plus archive tier, the capacity report should show the status of those tiers separately. Don't let the presence of files in a review system or dailies platform be mistaken for a complete data management strategy unless that platform is explicitly part of the verified backup plan.

Choose tools by storage type

There's no single monitoring tool that fits every media environment. A facility may need vendor admin consoles, SNMP monitoring, cloud-native reporting, MAM reports, and chat alerts working together. For on-prem shared storage, use the storage system’s own monitoring first. Systems such as editorial SAN and NAS platforms generally expose volume usage, client connections, bandwidth, logs, and sometimes SNMP. SNMP is useful because it lets a central monitoring system collect capacity and health signals without someone living inside the storage admin UI all day. For cloud object storage, use native metrics and inventory reports. Object storage tools can report total bytes, object counts, transactions, ingress and egress, and failed requests. Inventory reports are especially useful when you need object-level attributes such as size, age, versions, immutability, or encryption state. For review and collaboration platforms, pay attention to how the platform defines storage. Some systems separate uploaded file size from total usage because they generate extra playback, DRM, streaming, proxy, or thumbnail assets. A folder that appears to be using more storage than was uploaded may be behaving exactly as designed. For Microsoft 365, SharePoint, or similar collaboration storage, tenant reports can show total used, available, allocated, and growth over time. These are useful for production office documents and shared assets, but your team shouldn't treat them like editorial performance storage. For media asset management or production asset systems, report by production, folder, collection, status, and owner. This is where storage reporting becomes actionable because the team can connect capacity back to creative context. The strongest setup usually combines system-level monitoring with workflow-level reporting. System tools know the disks, buckets, and logs. Media tools know the shows, folders, deliverables, and owners.

Send alerts where decisions happen

Email-only alerts often fail in post environments because the people who need to act aren't always sitting in an admin inbox. Send capacity alerts to the channels where the team already coordinates work.

Capacity alerts should route to the places where the team can respond.

Good alert destinations include:

A post engineering or support channel for technical response.
A production-specific channel for storage ownership questions.
A ticketing system for cleanup, expansion, or archive tasks.
Email for formal escalation and vendor support trails.
An on-call or paging route for critical infrastructure events.

Write alert text specific enough that nobody has to ask, “Which storage?” A useful alert includes the storage name, project or production if known, current usage, free space, growth rate, estimated days remaining, threshold crossed, and the expected next action. For example: “Editorial_SAN_ShowA is at 86% used, 14.2 TB free, growing 4.8 TB/day over the last three days. Critical threshold is estimated under three days. Move inactive turnovers to nearline or expand allocation.” Avoid blasting every alert to everyone. Send warning alerts to storage owners and post management. Critical alerts should add engineering. Emergency alerts should add anyone who can pause ingest, approve expansion, or move work.

Account for latency and stale data

Not all reports are real time. Some admin and usage tools refresh hourly. Others update remaining data within 24 hours. Cloud providers may generate inventory reports daily, and very large buckets may produce multiple report shards rather than a single file. That delay is fine for capacity planning, but it's dangerous for incident response. If you need to know whether tonight’s camera cards will fit, don't rely only on yesterday’s inventory report. Pair slower reports with live metrics from the storage platform, transfer system, or cloud monitoring service. There's also a logging reality: not every storage log is complete in the way people imagine. Some cloud storage services create logs only when requests hit a given service endpoint, and request logging may be best-effort. Logs are still essential for investigation, but your team shouldn't assume that a missing log line always means nothing happened. This is where dashboards need labels. If a report is delayed, say so in the report title or description. If timestamps are UTC, say so. If usage includes generated derivatives, say so. Ambiguous reporting creates false alarms and bad cleanup decisions.

Make cleanup safe, not heroic

A capacity alert shouldn't send an assistant editor into panic-delete mode. Media cleanup needs guardrails. Safe cleanup is based on status, ownership, and redundancy. The team should know whether a folder is active, delivered, superseded, archived, backed up, or pending confirmation. Moving media from online to nearline is usually safer than deletion, and your team should delete only when you know the media is duplicated, verified, and no longer referenced by active projects. Common capacity problems tend to come from predictable sources:

Old exports left on online storage.
Duplicate turnovers from vendors.
Render caches and application caches that were never pruned.
Versioned objects or snapshots retaining deleted data.
Replication creating expected but unbudgeted second copies.

The pattern is that “full storage” usually reflects a retention policy, reporting gap, or ownership gap showing up as a disk problem.

Forecast capacity during pre-production

The best time to set up storage usage reports is before the show starts. Once the shoot is underway, everyone is reacting. During pre-production, ask for enough information to build a first capacity model:

Shooting format, resolution, codec, frame rate, and expected shooting ratio.
Number of cameras and shoot days.
Audio recording expectations.
Dailies, proxy, and editorial transcode formats.
VFX pull and turnover patterns.
Review platform usage.
Remote editorial or cloud workspace requirements.
Backup and archive targets.
Delivery and finishing storage requirements.

You don't need the estimate to be perfect, but you need it to be explicit. Once real ingest begins, compare actual growth against the model and adjust thresholds. If the show expected 3 TB per day and is actually ingesting 7 TB per day, your team should see that in week one, not discover it when the SAN is full.

Compare planned storage growth with real ingest growth and adjust thresholds early.

Regular reporting also helps with purchasing conversations. “We're at 68%” is weak. “At the current seven-day growth rate, the online pool reaches warning in nine days and critical in sixteen days, even after scheduled archive moves” is much easier to act on.

Keep the alert rules maintained

Storage monitoring requires ongoing maintenance because productions wrap, buckets get renamed, workspaces are reassigned, cloud lifecycle policies change, and review platforms alter how generated media is counted. A report that was accurate last season can become misleading. Review the alert configuration whenever the workflow changes. New camera formats, HDR finishing, remote edit, cloud dailies, virtual production, and large VFX pulls can all change the capacity curve. So can a new archive policy or a shift from local review files to generated streaming derivatives. The goal is to give the team enough warning to make calm decisions: archive this, expand that, pause ingest here, clean those folders, or change the retention rule. When your team ties alerts to workflow ownership and reports show growth over time, storage stops being a surprise crisis and becomes part of production planning.

FAQ

Track used capacity, free capacity, daily and weekly growth rate, client activity, ingress and egress, last access time, failed transfers, failed reads or writes, and application job errors. Percent used shows the current state, but growth and error trends show whether the team has enough time to act before production is affected.

Start with percent thresholds such as 80 percent warning and 90 percent critical, but adjust them based on days remaining. A better alert rule considers recent growth rate, peak ingest, time needed to archive or expand storage, and minimum free space needed for safe application behavior. For high-growth media volumes, a days-remaining threshold is often more useful than a fixed percentage.

For active productions, daily reports are useful for online, ingest, and cloud production storage. Weekly reports are usually enough for nearline, archive, and long-term capacity planning. During heavy ingest, finishing, or delivery periods, teams may also need live dashboards or intraday alerts because some inventory reports can lag by hours or a full day.

Send alerts to the places where the team already coordinates work, such as engineering chat channels, production-specific channels, ticketing systems, email escalation lists, or on-call paging systems. Warning alerts can go to storage owners and post management, while critical alerts should include engineering and anyone who can approve cleanup, expansion, archive movement, or ingest pauses.

Pre-production reports and estimates help set an initial storage model based on shooting format, codec, camera count, shoot days, audio, dailies, proxy creation, VFX turnovers, review usage, cloud workspaces, backup, archive, and delivery needs. Once real ingest begins, actual growth can be compared against the estimate so thresholds and purchasing plans can be adjusted early.

Wrapped projects should usually move off expensive online storage without disappearing from the team’s working memory. Aspect can archive projects for long-term storage while preserving previews, metadata, and AI access, which helps teams free active capacity while keeping the archive usable later.