Running out of disk space on hosting causes more damage than most people expect. It seems simple: space ran out, delete some junk and the site works again. In reality, files the site was writing at that moment get cut off halfway. So even after space is freed the site keeps returning 500 errors, because important files are already broken. Below are the typical consequences and the order in which to fix them.
What happens when the disk fills up
To write a file, a program opens it, truncates the old content and starts writing. If the quota runs out mid-write, the file is left empty or incomplete. WordPress rewrites .htaccess when permalinks are saved and when cache or security plugins run. If that happens with no space left, the file is cut short, Apache cannot parse it and the whole site returns 500. MySQL can also fail writes and in some cases mark a table as crashed, which visitors see as Error establishing a database connection or a blank page.
Step one: confirm and free space
The hosting panel shows disk usage and the limit, and the site error log usually contains No space left on device or Disk quota exceeded. Find the largest directories over SSH:
du -xh -d 2 ~ 2>/dev/null | sort -h | tail -15Backup plugins such as UpdraftPlus often keep archives inside wp-content. Download the one you need and delete the rest. Truncate large logs instead of deleting them, since some programs keep writing to the open file:
: > ~/www/example.uz/wp-content/debug.logStep two: the broken .htaccess
If 500 persists after freeing space, check .htaccess. If it ends mid-line, has an unclosed <IfModule> block or is empty, it was damaged when the disk filled. Apache's error log will show messages like RewriteRule: bad argument line or Invalid command. For WordPress, save a copy and replace it with the default rules:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressRestore any security, cache or redirect rules afterwards from a backup or by re-saving the relevant plugin settings.
Finding empty PHP files
If a plugin or core update was running, PHP files may be empty too. Find empty files changed in the last day:
find ~/www/example.uz -type f -name '*.php' -size 0 -mmin -1440Restore them from backup or reinstall the plugin. For empty core files, replace wp-admin and wp-includes from the official archive of the same version, leaving wp-content and wp-config.php untouched.
Step three: check the database
Use Check table in phpMyAdmin or mysqlcheck over SSH:
mysqlcheck -u db_user -p --check db_name
mysqlcheck -u db_user -p --auto-repair --check db_nameEvery table should report OK. Auto-repair works for MyISAM tables. InnoDB, which modern WordPress uses, does not support REPAIR TABLE, but it is transactional and far more resistant to partial writes. If an InnoDB table really is corrupted, restore the database from backup and contact technical support rather than experimenting with server recovery modes.
Example: a clinic website
A private clinic in Tashkent runs example.uz on WordPress with an online appointment form. Overnight a backup plugin started a full archive and filled the quota. In the morning the site returned 500. Deleting old archives did not help; .htaccess had been cut off in the middle of the security plugin's rules. Replacing it with the defaults brought the site back, but the form failed. mysqlcheck showed the form plugin's old MyISAM table was crashed, and --auto-repair fixed it. The security plugin settings were re-saved and the backup plugin was set to send archives off the hosting account.
Preventing a repeat
Disks rarely fill suddenly; space disappears gradually over weeks. Check usage in the panel at least monthly, limit how many backups plugins keep, and enable WP_DEBUG_LOG only while debugging. If the site is simply growing, a larger plan can be arranged through the sayt.uz cabinet or technical support.