Server disk full stopping the website

How a full disk stops the site

A server disk full does not produce one neat error; it produces the full alphabet of trouble. The filesystem cannot write, and the first process that fails varies:

• Web server: fails to write sessions, uploads, or temporary render files, and returns 500.
• Database: cannot write to the data file, the WAL, or the temp tables, so every query errors; the site falls over even when PHP is fine.
• Logs: the app's log rotator fails, often silently, so a small disk is always the last act of the highest failure.
• Build / deploy: the deploy job cannot stage files, so a fresh content update silently never ships.

The interesting fact about a disk full site: the shell keeps running, the server is up, but the site inside it dies one layer at a time.

The proof

1. From the terminal (if you have shell access): df -h / shows the mount's usage. df on the data mount, not just the system mount.
2. From cPanel: the "Disk Usage" page in the Files section, which shows per-account usage.
3. From the site: create a two-byte file (echo x > /tmp/x on the shared host) and read back. A write error is the exact confirmation.

Find the big files

Useful commands, depending on access:

du -sh -- * | sort -h   # per-folder sizes (account root)
find . -type f -size +100M 2>/dev/null   # biggest files anywhere

du -sh -- * detects the account size with a reverse output. Sort by folder and see which single folder eats the space before touching anything.

The safe clearing order

1. Backup a copy of anything you are about to delete if it has any value beyond "temporary".
2. Clean the logs. Rotate them (gzip, delete older than a week) instead of deleting active files: logrotate or the host's interface.
3. Clear caches and old build artifacts.
4. Delete old .sql dumps and old uploaded files that are no longer linked.
5. Run the cleanup a second time after a day; a disk that fills back fast has a leak (a runaway log, throttled writes, a mailbox), and the prompt list wise to find the leak.

Never "rm -rf" a production directory by memory. On a shared host, the tmp folder may be shared, and the cache might be needed by the plugin's own config.

When you have no shell

On a shared or cPanel-only host:

• Use the host's "File Manager" to sort by size, and the Terminal feature if available.
• Purge the site's caches in the CMS (WordPress, Magento, or a page cache) first; caches are the largest reclaimable files with the lowest risk.
• Empty the trash in the CMS and clear the .log files in the root.
• Contact the host if the account disk is still full after you remove the obvious outliers; 60% of the account disk is often held by the mail and the backups the host manages.

Prevention

• Put the log rotator on a schedule and a maximum size, plus the cron that will clean the old sessions.
• Watch the disk usage, not the site: a degrade is the same as the site error page but earlier.
• Move the backups and archives to a fixed store, not the live disk.
• Alias an alert at 80% full, and a second one at 90%, so the site never has to die to get attention.

When a full other disk is the cause

Some hosts have slower disks or a separate mount for /tmp or the mail spool. If the site dies while df -h / looks clean, check df -h /tmp and the mail queue. A filled /tmp mimics every symptom of the site outage with no change visible in the account disk numbers.