A WordPress site that throws 507 Insufficient Storage is telling you the server had nowhere to write. You click Update on a post, upload an image or run a plugin update, and instead of a success message you get a plain page that says “There is insufficient free space left in your storage allocation.”
It mostly hits sites on shared hosting with a fixed disk or inode quota, usually cPanel accounts on Apache or LiteSpeed. Sometimes only wp-admin breaks, sometimes the whole front end goes down with it.
I already wrote about the PHP side of a full disk in Disk Quota Full in WordPress: Fix HTTP 500 and Failed Updates. This post is about the 507 status code itself: what it means, where it comes from and how to clear it for good.
What a 507 actually means
507 was not made for WordPress. It comes from WebDAV, the file-editing extension to HTTP, where it is defined in RFC 4918 as “the server is unable to store the representation needed to successfully complete the request.”
The RFC calls the condition temporary. MDN’s page on 507 lists the usual causes: directories running out of space, not enough RAM for an operation, or an internal limit being reached.
On a WordPress host that almost always means one of these is full:
- the disk quota of your hosting account
- the inode (file count) quota, even when there is free space left
- the
/tmpdirectory or partition, where PHP stores uploads before WordPress moves them
That last one explains a pattern people report on the forums: the 507 appears when two authors save posts at the same time, then disappears on refresh, and the cPanel error log shows nothing. The moderator’s answer there was a full /tmp allocation, which only overflows when several requests write at once.
You may also see “a 507 Insufficient Storage error was encountered while trying to use an ErrorDocument”. That is Apache failing to load your custom error page for the same reason. It is not a second problem.
Step 1. Check disk and inode usage
In cPanel, open Files » Disk Usage. It shows how much each directory in your home folder takes, sorted against the largest one. The cPanel docs warn that the figures may not reflect recent changes, so do not panic if the number does not drop the second you delete something.
If you have SSH, the terminal is faster. Check your quota first:
quota -sYou should see your used space and limit under “space” and your file count and limit under “files”. If either is at or above the limit, you found the cause. If the command is missing, use the Disk Usage page or ask your host for the numbers.
Then list the biggest folders in your home directory and in wp-content:
du -sh ~/* ~/.[!.]* 2>/dev/null | sort -h | tail -15
du -sh ~/public_html/wp-content/* | sort -hThe largest directories end up at the bottom. For inodes, count files per folder instead of bytes:
du --inodes -s ~/public_html/wp-content/* | sort -n | tail -10A cache folder with hundreds of thousands of files is the classic inode eater. It can push you over the file limit while the disk itself is half empty.
Step 2. Delete old backups first
I always look at backups first, because they are usually the biggest thing on a full WordPress account. Backup plugins keep archives inside wp-content by default, and each one is a full copy of the site.
Look for large archives anywhere in your home directory:
find ~ -type f -size +100M -exec ls -lh {} \; 2>/dev/nullCommon folders are wp-content/updraft, wp-content/ai1wm-backups and whatever cPanel or Softaculous backups you created by hand. Download the newest one to your computer, then delete the rest. Backups in the document root are also a security risk, which I covered in Never, EVER leave any backups inside your domain document root.
Step 3. Clear cache, logs and error_log files
Page cache is safe to delete because the plugin rebuilds it. Purge it from the plugin settings, or empty wp-content/cache if wp-admin will not load.
Next, PHP error_log files. On cPanel they appear in every folder where a PHP error happened, and a single noisy plugin can grow one to gigabytes. Find them:
find ~/public_html -type f \( -name error_log -o -name debug.log \) -exec ls -lh {} \;Open the biggest one and read the last lines before deleting it. Whatever filled it will fill it again. When you know the cause, remove them:
find ~/public_html -type f \( -name error_log -o -name debug.log \) -deleteAlso check ~/tmp and ~/logs in your home directory. Old session files and archived access logs pile up there quietly.
Step 4. Shrink the database
cPanel counts database size toward your disk usage. Back up the database before you touch it, then see which tables are biggest:
SELECT table_name,
ROUND((data_length + index_length) / 1024 / 1024, 1) AS size_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY size_mb DESC
LIMIT 10;Bloated wp_posts usually means revisions, and a huge wp_options often means leftover transients. With WP-CLI you can clear both, plus the trash:
wp db export ~/before-cleanup.sql
wp transient delete --expired
wp post delete $(wp post list --post_type=revision --format=ids) --force
wp post delete $(wp post list --post_status=trash --post_type=any --format=ids) --forceThe transient command ends with “Success: N expired transients deleted from the database.” If a wp post delete line complains about missing arguments, there were no revisions or trashed posts to delete.
💡 The export lands in your home directory, outside public_html. Download it and delete it once the cleanup is done, or you just added a new file to a full disk.
For more detail and a plugin-free SQL route, see Delete Unused Post Revisions.
When there is free space and you still get 507
If your quota is clearly not full, the limit being hit is not yours to see. Two cases come up.
The first is the server’s /tmp or /home partition being full for everyone on it. You cannot fix that from your account. Send your host the time of the error and ask them to check partition usage with df -h and df -i.
The second is a resource limit dressed up as a storage error. In a 2026 WordPress.org forum thread, a host traced a 507 to a plugin holding table locks, which caused long PHP timeouts and used up the account’s entry processes. Disabling the plugin brought the site back, although the plugin author disputed the diagnosis.
So if disk and inodes look fine, look at the resource usage page in cPanel (on CloudLinux hosts) and deactivate recently added plugins one by one.
Keep the disk from filling up again
Clearing space fixes today. Changing where the space goes fixes next month.
Send backups to remote storage (S3, Google Drive, an SFTP box) and keep only a few copies. A backup on the same account protects you from almost nothing and eats the quota.
Cap revisions and empty the trash sooner. Back up wp-config.php and add these lines above the “That’s all, stop editing!” comment:
define( 'WP_POST_REVISIONS', 5 );
define( 'EMPTY_TRASH_DAYS', 7 );
WordPress then keeps at most five revisions per post and empties the trash after seven days instead of the default 30.
Leave WP_DEBUG_LOG off on production unless you are actively debugging. And fix the PHP warnings that fill error_log instead of deleting the file every week.
💡 Exclude cache and backup folders from your host’s own backups too, or every backup copies the previous backups.
If you run your own server with OpenPanel, users get a Disk Usage page with a per-directory chart and a separate Inodes Explorer, so the check from Step 1 works much like cPanel’s Disk Usage tool. Having the inode breakdown by folder in the panel saves you the du --inodes command over SSH.
Finally, set a reminder to look at disk usage once a month. As of November 2026, shared hosting plans commonly come with both a disk and an inode quota, and WordPress gives you no warning before either one is full.
TL;DR: a 507 means the server could not write what WordPress asked it to store. Check your disk and inode quota, delete old backups, cache and error_log files, trim revisions and transients, then move backups off the account so the quota does not fill up again. If nothing is full on your side, ask your host about /tmp and resource limits.
