Tableau Cloud storage limits: how sites hit the wall, and how to see it a month early

Of all the ways a Tableau Cloud site gets into trouble, storage is the most polite. It does not spike, it does not page anyone at night, and it gives months of warning to anyone who looks. Sites hit the wall anyway — because the warning Tableau sends arrives at the wall, not before it, and because the number everyone glances at is the level, when the number that matters is the slope. This guide covers how the quota works, what the platform does natively, and how to read your own storage trajectory from data Tableau already gives you.

How the quota works

Each Tableau Cloud site has a storage quota. Extracts, workbooks and their history consume it; growth is usually steady and boring — a little more each week as extracts refresh, content accumulates, and revision history piles up behind the scenes. Steady and boring is exactly why it gets ignored until it isn't: nothing about a chart that climbs half a percent a week demands attention on any given day, and so no given day is the day anyone looks. The wall does not move, the line does not stop, and the interesting question — when do they meet? — belongs to nobody.

It belongs to nobody partly because storage is nobody's job. The people publishing content see their own workbooks, not the site total; the site admin sees the total, but not which team's extracts are moving it; and the person who signs the capacity request sees neither until an email arrives. Each of them is doing their part correctly. Nothing in the default arrangement makes the site's growth anyone's number to watch.

What Tableau does natively

Tableau emails site admins when storage crosses a fixed threshold. That is the alerting story. The level isn't customizable, there's no cause attached — the email tells you the site is full, not what filled it — and by definition it arrives when you're already at the wall. At that point your options are the urgent kind: delete something today, or have the capacity conversation under deadline. Useful as a fact, useless as a warning. (Broader native alerting and annual reviews are limited to the highest support tiers.)

The result is a strange asymmetry: the platform measures your storage continuously, stores the readings, and then tells you about them exactly once, at the moment the information is least actionable.

And the moment matters, because a full site is not a graceful failure mode. The cleanup that would have been a calm quarterly chore becomes an emergency triage of other teams' content; the capacity request that would have taken a procurement cycle now needs an exception. Everything about hitting the wall is more expensive than approaching it — which is the entire argument for reading the approach.

Why the level was never the useful number

Two sites at 80% are not in the same situation: one has been at 80% for a year; the other is climbing half a percent a week. Any alert keyed to the level treats them identically — silent about both today, then eventually loud about both, with wildly different amounts of notice. The level tells you where you are; only the trajectory tells you when it becomes a problem.

Storage is the cleanest example in all of Tableau Cloud of a metric where the derivative matters more than the value. The value is a fact about today; the slope is a forecast, and a forecast is the only thing you can act on early. "79% full" starts an argument about whether 79 is a lot. "Full in five weeks at the current rate" starts a cleanup — same site, same data, different number.

Reading your own trajectory

The Activity Log includes periodic site storage samples, which means your site's growth curve is already in your data — and a curve implies a date. Reading it reliably takes more care than it looks (partial days and short baselines both lie), but the principle stands: the trajectory is knowable well before the threshold email.

What actually frees storage

When the date lands closer than anyone likes, the usual wins, in order:

• Stale extracts nobody has opened in 90+ days — often a quarter of total extract storage. Content that is refreshed on schedule and read by no one is the single most common finding, and the safest to act on.
• Duplicate data sources maintained by different teams. Two teams, one upstream table, two full extracts of it — consolidation halves the footprint and removes a consistency argument at the same time.
• Oversized extracts that should be filtered or aggregated. An extract carrying every row and column "just in case" is paying storage for data no view reads.
• Old workbook revision history, accumulating quietly behind every frequently-republished workbook.

The pattern behind all four: storage problems are usually content hygiene problems wearing a capacity costume. A quarterly cleanup against a stale-content report keeps most sites permanently clear of the wall — the same discipline covered in our guide to finding and retiring stale content, applied before the wall makes it urgent.

Two practical notes on running that cleanup. First, retire with notice, not by surprise: a short message to each owner — "this has not been opened in months; we plan to archive it on this date unless you say otherwise" — turns a deletion into a decision, and the silence you usually get back is the consent you need. Second, keep a record of what was removed and how much it freed. That record is what makes the next quarter's cleanup a routine rather than an argument, and it is the evidence that a capacity request, when one is finally justified, is asking for room to grow rather than room to hoard.

VizBolt's Storage Capacity Trajectory signal does this math continuously and warns with a date — in one real case, 33 days before the threshold email would have arrived. → Predictive Alerts