A primary school used a gallery plugin on its WordPress site to publish photographs from events. The plugin did what such plugins do: for every uploaded picture it generated several resized copies, so that the page could load a small version in a grid and a larger one in a lightbox. Nobody at the school knew how many copies that meant, and the number mattered a great deal on the morning after sports day.
After the event, several teachers uploaded two thousand pictures between them, straight from their phones, each several megabytes. The plugin created dozens of thumbnails and intermediate sizes for each. The account hit its disk quota in the small hours, and the site began failing to save anything.
The arithmetic nobody did
A phone photograph is typically 3 to 6 MB, at a resolution of 12 megapixels or more. WordPress itself generates a few smaller sizes on upload (thumbnail, medium, large and a couple of others), and themes and plugins often register more. This school's theme added four, and the gallery plugin added six of its own, including two high-resolution variants for dense screens.
That makes roughly twelve files per upload, with the original included. Take an average original of 4 MB; the generated copies are smaller but not trivially so, since the large ones are close to a megabyte or two each. The total per picture comes to about 9 MB. Two thousand pictures at 9 MB is around 18 GB.
The school's hosting plan had 20 GB of disk space, of which the existing site, email and backups already used about 7 GB. The sums do not work, and they stopped working at about three in the morning.
What failed first
When a disk quota is reached, writes fail. Not just uploads. PHP stores session data in files, and WordPress and its plugins write caches, logs and temporary files. The first visible failure was that parents could not log in to the members' area: the login form accepted the password, then could not write the session file, and sent them back to the form.
Then the site began to show errors to visitors. The school's theme had error display switched on from the time it was built, so a parent saw a message that included the phrase "No space left on device" and a full file path, which is both unhelpful and slightly embarrassing. Contact forms stopped sending. Email delivery to the school's mailboxes also stopped, because the mail system shares the same quota on many hosting plans, and incoming messages were rejected or deferred with a "mailbox full" style response.
It is a pattern worth recognising: when many unrelated things fail at once, and none of them has anything to do with each other, check the disk before anything else.
Finding the cause
The office administrator rang the host at 8:10. The agent looked at the account's disk usage, saw 100 percent and asked what had changed. The answer, sports day photographs, was available in two minutes. What took longer was finding where the space had gone, because the control panel reported only a total.
From a shell, or from the panel's disk usage tool, the question is answered with du:
cd ~/public_html/wp-content
du -sh uploads/* | sort -h | tail
du -sh uploads/2025/051.2G uploads/2024
2.8G uploads/gallery-cache
17.6G uploads/2025One folder for the current month accounted for almost everything. Inside it were files named like IMG_4821-300x200.jpg, IMG_4821-768x512.jpg, IMG_4821-1536x1024.jpg and so on, repeated two thousand times. Seeing the pattern of repeated suffixes is what made the problem obvious, and also the fix.
The fix, in order
First, free enough space for the site to work again. Deleting the generated copies of the newest uploads is safe, since they can be regenerated from the originals, but doing so by hand in a panic invites mistakes. The cleaner approach was to remove the gallery plugin's own cache folder, which the plugin rebuilds on demand, freeing about 2.8 GB. That was enough to bring logins and forms back within a few minutes.
Second, deal with the real size problem. The teachers' originals were far larger than any web page needs. A photograph displayed at most 2000 pixels wide does not need a 4000 pixel original. The school installed an image optimisation plugin, with a rule to downscale anything over 2560 pixels on its long edge on upload, and ran it over the existing files in batches, overnight, to avoid a repeat.
Third, remove sizes nobody used. Two of the gallery plugin's variants were never displayed, since the theme's grid did not call for them. Turning them off in the plugin settings cut the per-photo total by about a third.
Finally the quota was increased with the plan, and a disk alert was set at 80 percent. The extra space was the least important of the four changes.
Verifying it
You can find your own exposure in ten minutes. Look up your quota in the control panel and note how much of it is used. Then look at where the usage sits, using the panel's disk usage page or du. For the uploads folder, count the files:
find wp-content/uploads -type f | wc -l
find wp-content/uploads -type f -name "*-[0-9]*x[0-9]*.jpg" | wc -lIf the second number is several times the number of media items in your library, you are keeping a lot of generated copies. Check also what else counts toward the quota: mailboxes, backups stored in your own account, log files and stray archive downloads are common contributors. The page weight tool helps judge whether the images you serve are larger than they need to be.
| Thing that fills the quota | Typical sign | Where to look |
|---|---|---|
| Generated image sizes | Many files with -300x200 suffixes | wp-content/uploads |
| Local backups | Large .zip or .tar.gz files | Home directory, plugin backup folders |
| Mailboxes of several GB | Mail section of the panel | |
| Logs | Huge error_log files | Site folders, ~/logs |
One more thing is worth checking after any cleanup: the backups. If the host or a plugin stores nightly backups inside the same account, they count toward the quota too, and a full disk can make the backup itself fail, so the one night you needed it you find the last good copy is a week old.
What the school changed afterwards
The deputy head asked for a policy that teachers could follow without technical knowledge. It fitted on one side of A4. Photographs for the website are chosen, not dumped: twenty good pictures from an event rather than two thousand. They are resized on the teacher's own computer or with the plugin's upload tool before they go anywhere. Anything bigger goes into the school's shared storage, which has its own space and its own limits, and the website links to an album rather than holding every file.
The administrator also added a standing item to the half-termly checklist: look at the disk usage figure and write it down. Two numbers from successive terms make a trend, and a trend makes a problem visible months before it becomes an outage. The figure had been growing by about 1.5 GB a term for years, and nobody had known.
What would have caught it
- Limiting upload sizes and dimensions, with automatic downscaling on upload to a fixed maximum width.
- Knowing what the gallery plugin and the theme generate for each picture, and disabling sizes that are never shown.
- A disk usage alert at 80 percent, sent to a person who reads it.
- A rule for events: photographs are resized before upload, or uploaded in batches that someone watches.
- Turning off on-screen error display on the live site, so that full paths and error text are not shown to parents.
- A periodic look at the largest folders, once a quarter, so that growth is a known number and not a surprise.