Your homepage and wp-login.php both return HTTP 500, an email says the automatic update could not be completed, and debug.log is empty or missing. Before you start disabling plugins, look at the disk usage in your hosting panel.
A support thread from this week shows the pattern well: a shared hosting account at 1020 MB of a 1000 MB quota, a 500 error everywhere, and a WordPress 7.1.3 auto-update that stopped halfway. If your panel shows the account at or over its limit, nothing else will work until you free space.
This applies to any shared hosting account or small VPS with a hard quota. As of 2026-11-04, WordPress 7.1.4 is a security release that sites with background updates install on their own, so a full disk is currently also blocking a security update.
Confirm the disk is really the problem
A quick test: open /license.txt or /readme.html on your domain. If static files load but every PHP page returns 500, the web server is fine and PHP is the part that is failing.
Then check the numbers over SSH. Run this from your home directory:
du -sh ~
df -h ~du prints how much your account uses. df shows the server’s filesystem, which on shared hosting is not your quota, so trust the panel figure over df there.
💡 Many panels cache the usage figure. If you delete files and the number does not move, wait a few minutes or ask the host how often it refreshes before you delete more.
Find what is eating the space
List the biggest folders in your home directory, largest first:
du -h --max-depth=1 ~ 2>/dev/null | sort -rh | head -20Then drill into WordPress itself. Run this from the site root (the folder with wp-config.php):
du -h --max-depth=1 wp-content 2>/dev/null | sort -rh
find ~ -type f -size +50M -exec ls -lh {} \; 2>/dev/nullThe second command lists every file over 50 MB with its size. On WordPress sites the same few things show up again and again:
- Backup archives from backup plugins, for example
wp-content/updraft/orwp-content/ai1wm-backups/, often with months of copies nobody rotated. - Page cache folders under
wp-content/cache/. - A
wp-content/debug.logleft running on a live site for months. error_logfiles that PHP writes into every folder that throws warnings.- Leftovers in
wp-content/upgrade/andwp-content/upgrade-temp-backup/from interrupted updates. - The WP-CLI download cache in
~/.wp-cli/cache/, which keeps a zip of the core versions it fetched. - Old
.zipand.sqlfiles someone left in the home folder or the document root.
To find the scattered PHP error logs:
find ~ -type f -name error_log -size +5M -exec ls -lh {} \; 2>/dev/null💡 Do not free space by deleting images from wp-content/uploads/. Your posts still reference them, so you trade a 500 error for broken media and layout gaps.
Step 1. Get the big files off the server first
Download any backup archives and database dumps you want to keep to your own computer before you delete them. A backup stored on the same account that just ran out of space is not much of a backup anyway.
If you have no recent backup at all, make one now before deleting anything: download wp-config.php and wp-content over SFTP and export the database from phpMyAdmin, straight to your computer, not to the server.
If those archives sit inside public_html, anyone who guesses the file name can download them too. I wrote about that in never leave backups inside your document root.
Step 2. Clear what is safe to delete
All of these are rebuilt automatically or are useless once the site is healthy again. Run the commands from the WordPress root:
# page cache (the cache plugin rebuilds it)
rm -rf wp-content/cache/*
# leftovers from interrupted updates
rm -rf wp-content/upgrade/*
# empty a huge debug.log without deleting the file
: > wp-content/debug.log
# WP-CLI download cache
wp cli cache clearwp cli cache clear should print Success: Cache cleared. If WP-CLI itself errors out because PHP cannot start, delete ~/.wp-cli/cache/core/ by hand instead.
Leave wp-content/upgrade-temp-backup/ alone until updates work again. WordPress uses it to restore a plugin or theme when an update fails, so empty it only once the site is stable.
If the database counts toward your quota (it does with many hosts), check which tables are big:
wp db size --tables --human-readableStep 3. Finish the update that broke halfway
Once there is free space, look for a .maintenance file in the WordPress root. An interrupted update can leave it behind, and then visitors see the “Briefly unavailable for scheduled maintenance” message. Delete it.
ls -la .maintenance
rm .maintenanceThen check whether the core files are complete:
wp core verify-checksumsOn a clean install it prints Success: WordPress installation verifies against checksums. If it lists missing or changed files, download a fresh copy of core over the top without touching wp-content, then run the database upgrade:
wp core download --version=7.1.4 --skip-content --force
wp core update-dbReplace 7.1.4 with the newest version if a later one is out when you read this. Without WP-CLI, follow the manual process in the official upgrade guide: back up, keep wp-config.php and wp-content, replace everything else. I also covered reinstalling core with WP-CLI in more detail.
Why a full disk looks like a PHP crash
PHP needs to write while it runs: session files, temp files for uploads, cache, logs. When the quota is hit, those writes fail. Depending on the host and the code, you get a blank page, a 500, or an error that points somewhere else entirely.
Updates fail first because WordPress downloads the package, unpacks it into wp-content/upgrade/, and keeps a copy of the old plugin or theme while it swaps files. For a moment that needs several times the size of the package, so a site at 98% can run fine for weeks and then die during the next update.
It also explains the empty log. Logging is a write too, so WP_DEBUG_LOG cannot help until there is space again. If the log still does not appear after the cleanup, see debug.log not created in WordPress.
Stop the disk from filling up again
Most of this comes down to retention. Set your backup plugin to keep two or three copies and send them to remote storage instead of the hosting account itself.
Turn off WP_DEBUG_LOG on production once you are done troubleshooting, or at least rotate the file. And look at the usage graph once a month instead of waiting for the next failed update email.
In OpenPanel you do the same hunt from Statistics > Disk Usage, which shows a chart and a table of folder sizes you can click into, much like the Disk Usage tool in cPanel. Next to it is an Inode Usage page, which helps when you hit the file count limit rather than the size limit, for example with a cache plugin that writes thousands of small files.
TL;DR: If static files load but every PHP page returns 500 and an update just failed, check the disk quota first. Find the big folders with du, move backups off the server, and clear the cache, logs and wp-content/upgrade. Then remove .maintenance, run wp core verify-checksums, and reinstall core if anything is missing.
