Managing Zendesk Storage Limits Before They Bite

Here's what the page looks like once you find it, and what each figure is actually counting.

The three counters

Admin Center, Account, Usage, Storage. It sits under Usage rather than Billing, which is one of several places the Admin Center layout sends people the wrong way. Zendesk documents it in Managing data storage in your Zendesk account. It opens with three cards.

On our developer instance: data storage 4.6 MB, file storage 561.8 MB, external content storage 0 MB. The ceilings differ too, at 11,000 MB, 60,000 MB and 1,000 MB respectively.

Those are one instance's numbers and yours will differ. What generalizes is the ratio. Files are using roughly 122 times what the structured data uses, against a ceiling only about five times larger.

That shape is normal, and it's why "we have a lot of tickets" is rarely the storage problem. Ticket text is small. A ticket is a few kilobytes of words and metadata. A screenshot somebody pasted to show you the error is a few hundred kilobytes on its own, and a phone video of a broken product is tens of megabytes.

Where your own numbers come from

Those ceilings are not arbitrary and they are not the same as ours. Zendesk's guide to managing data storage sets out the formula: "a base storage amount for all plans and an additional per-seat allocation that varies per plan type."

The base is 10 GB of data storage and 10 GB of file storage on every plan. The per-seat part is where plans diverge: Team adds 50 MB of data and 2 GB of files per agent, Growth and Professional add 100 MB and 5 GB, and Enterprise and Enterprise Plus add 200 MB and 10 GB. External content storage does not scale per seat at all; it is 100 MB on Team, 500 MB on Growth and Professional, and 1 GB on Enterprise and Enterprise Plus.

Our own numbers fall out of that, with a caveat worth learning from. An 11,000 MB data ceiling and a 60,000 MB file ceiling is a 10,000 MB base plus per-seat allocation, and two combinations produce exactly those figures: ten seats at Growth or Professional rates, or five at Enterprise rates. The big counters cannot separate them.

The third card can. Ours reads 1,000 MB of external content storage, and external content does not scale per seat: it is 500 MB on Growth and Professional, 1 GB on Enterprise and Enterprise Plus. So this is a five-seat Enterprise-tier account, and the two large numbers on their own would have had us guessing wrong.

Run the arithmetic backwards on your own page and it will narrow your plan considerably. Read the external card before you commit to an answer, because it is the one that breaks the tie.

So your ceiling is base plus seats, which has a consequence people miss: buying an agent buys storage. A team that adds ten Professional seats gains 50 GB of file allowance without anyone deciding to. And a team that reduces seats loses it, which is the version that surprises people, because the tickets and attachments do not leave when the agents do.

What each counter holds

Data storage is the structured content: tickets, users, and custom objects. The Storage usage page describes it in the line visible in the screenshot above: "The total size of all data storage objects in Support. Data is limited to the past 3 years."

That three-year window is worth pausing on. It means the number on the card is not your all-time footprint, so an instance with a decade of history is showing you a partial figure. If you're planning around growth, you're extrapolating from a rolling window.

File storage is attachments on tickets, with the same three-year framing. This is the counter that moves.

External content storage covers content indexed from outside Zendesk. On our instance it's zero, and on many instances it stays zero until somebody connects an external source for search or an AI agent to read from. It's the smallest ceiling of the three by a wide margin, which matters if you start indexing a large documentation site.

Why the split matters more than the totals

The two big counters fill at completely different rates, so the useful question is which of them hits its ceiling first, and when.

Data storage grows with ticket volume, roughly linearly and slowly. You can forecast it from your ticket count with reasonable confidence.

File storage grows with what people attach, which is not a function of your volume at all. It's a function of your product and your customers. A support desk for a SaaS tool collects screenshots. A support desk for physical goods collects photos and increasingly video, and the same ticket count produces an order of magnitude more storage. Two companies with identical ticket volumes can be years apart on file storage.

That means a forecast built on ticket growth will be wrong in the direction that hurts, because the counter you can predict isn't the counter that fills.

The per-attachment ceiling

There's a fourth number, and it doesn't appear on the storage page at all. Each attachment has a maximum size, and the account settings endpoint returns it as limits.attachment_size, in bytes. If you have not used the API before, our Zendesk API guide covers authenticating a request like this one:

52,428,800 bytes, which is fifty megabytes per file on our instance. That's the cap a customer hits when they try to send you a video, and it's the setting that quietly shapes your file storage curve, because it sets the size of the largest single thing anyone can add.

It's worth knowing this number before you go looking for ways to slow storage growth, since lowering it is one of the few levers that acts on the input rather than the accumulated total.

Reading the charts

Below the cards, each counter gets a time-series chart with a range selector and a line marking the limit.

On a young or low-volume instance these charts are flat, and ours are: a line along the bottom and the ceiling drawn far above it. Flat charts are not useless, though they're easy to dismiss. The thing to look for is not the current height but the gradient, and on a busy instance the gradient is the whole story. A line that has doubled its slope in the last quarter tells you something a single "used" figure never will.

Set the range to the longest available and look at the shape, remembering that the dashboard only began collecting in May 2023, so anything earlier reads as zero. If it bends upward, you have a date, and knowing the date is what turns this from a surprise into a plan.

What to do when a counter climbs

The options are narrower than people expect, and they divide cleanly.

You can delete things, which is what deletion schedules are for, and which sits alongside the other retention settings in our Zendesk security checklist. Attachments have their own object type there, so if file storage is your problem you can target attachments specifically without touching ticket history. That's usually the right first move, because it removes the megabytes while keeping the conversations searchable.

You can stop things arriving, by capping attachment sizes or steering large files elsewhere. This is a policy decision more than a technical one, and it has a real cost: an agent who can't see the screenshot solves the ticket slower. Be careful about optimizing storage at the expense of resolution time, since one of those is cheap to buy more of and the other isn't.

You can buy more, which is the option Zendesk would prefer and is sometimes simply correct. It is sold in units. Each More Storage unit adds 500 MB of data, 25 GB of files and 500 MB of external content, bought from the storage dashboard itself. The cart recommends a quantity based on your past usage, which is the incentive below made concrete.

Worth knowing what the ceiling actually feels like, because it is less dramatic than people fear and less harmless than they hope. At 80% you get an in-product warning and the chart line turns orange. Past the limit you get an in-product error and the line turns red. Zendesk is explicit about what it may do next: it "always reserves the right to enforce product limits, including charging for additional usage or curtailing usage if the limits are surpassed."

Nothing breaks at the threshold, in other words, and nothing protects you either. Separately, exceeding storage is not a performance problem — Zendesk answers that question directly and the answer is no.

The incentive here is worth naming rather than resenting. Storage is a metered resource with a real underlying cost, and the counter that grows fastest is the one tied to customer behavior you don't control. That's a comfortable position for a vendor: the overage arrives whether or not you changed anything, and the cheapest response for a busy admin is to pay it. That doesn't make the pricing wrong. It does mean the decision to buy should follow a look at the chart rather than an email about a threshold, because the two prompts lead to different-sized purchases.

The audit worth running once

Three questions, answerable in a few minutes on the page itself.

Which counter is closest to its ceiling, as a percentage rather than in megabytes? Megabytes are the wrong unit for this, because the ceilings differ by more than an order of magnitude. On our instance file storage is the larger number by far and still sits at about 0.9% of its limit, while data storage is at roughly 0.04%. Both are comfortable; they are not comparable.

What's the gradient on the longest range you can select? A flat line means you can stop thinking about this for a year. A bend means you should put a date in the calendar.

Is external content storage doing anything? If you've connected external sources, check it, because it has the smallest ceiling of the three and it's the one nobody watches.

Write the three answers down. That's your storage position, and it takes longer to describe than to do.

Common questions

Where is the storage page in Zendesk? Admin Center, then Account, then Usage, then Storage. It's under Usage rather than under Billing, which is where people tend to look first.

Why is my file storage so much bigger than my data storage? Ticket text is small and attachments are not. On our instance files use about 122 times what structured data uses. A single screenshot can outweigh hundreds of tickets' worth of text.

Does the storage page show my all-time usage? The Storage usage page says so in the product: "Data is limited to the past 3 years." Treat the card as a three-year window rather than a lifetime total.

How do I reduce file storage without deleting tickets? Attachments are a separate object type for deletion schedules, so you can schedule attachment deletion while leaving the tickets themselves in place. The conversation stays searchable and the megabytes go.

What counts as external content storage? Content indexed from sources outside Zendesk. It's zero on instances that haven't connected any, and it has a much smaller ceiling than the other two counters, so it's worth checking if you've recently added a source.

Where an AI layer fits

The split between the two counters has a consequence for automation that is worth spelling out, because it points the opposite way from the obvious one.

The counter under pressure is file storage. The counter an AI agent actually reads is data storage: ticket text, subjects, comments, the words people wrote. Those are separate ceilings, and the one filling up is not the one holding the material an agent works from. So the storage remedy that costs you nothing is attachment deletion, which frees megabytes at the rate they accumulated while leaving every conversation searchable and every answer still derivable.

That makes the sequencing easy where it usually is not. Attack file storage first, because it is both the bigger number and the one you can cut without touching what anybody, human or automated, reads later. Only then consider ticket retention, which is where the trade-off actually bites.

Macha reads from your existing Zendesk rather than storing a second copy, so it adds nothing to either counter. One caveat follows straight from the counters. If your tickets carry their answers in attachments, a screenshot of the error rather than a description of it, then the text an agent reads is thinner than the ticket looks, and your file storage problem and your automation ceiling turn out to have the same cause. That is the wrong fit if you were hoping an agent would read the screenshots; it reads the words. Our Zendesk integration page sets out exactly what gets read.

Start a free trial.