You got an email from your hosting provider saying your inode limit is near or exceeded. Or your site started behaving strangely: forms stopped working, new posts would not save, emails stopped arriving, and the admin dashboard began throwing errors you had never seen before. If you are on shared hosting and none of these symptoms make sense, the inode limit is one of the most common causes that goes completely undiagnosed for hours or days because most people have never heard the term before.
This guide explains exactly what an inode is, what actually breaks when the limit is hit, why shared hosting imposes these limits in the first place, what the most common causes are, and a specific step-by-step process to diagnose and reduce your inode count without breaking anything. It also covers the point where cleanup is no longer the answer and an upgrade or platform change is the appropriate response.
What an inode actually is, in plain terms
An inode (index node) is a record in the file system that represents a single file, folder, or link on your hosting account. Every item stored on the server gets one inode: an image file, a PHP script, a text file, a directory, a symbolic link, a cache file, a session file, even an email message in some configurations. The inode does not store the actual content of the file. It stores the metadata: what kind of object this is, who owns it, when it was created and modified, how big it is, and where the actual data is located on the disk.
The inode limit is the maximum number of these records your hosting account is allowed to have. Most shared hosting plans set this between 100,000 and 250,000 inodes. Hostinger allows 200,000 on most plans. HostGator has a soft limit at 100,000 and a hard limit at 250,000. SiteGround limits accounts to 250,000. The specific number varies by provider and plan tier, but the category is consistent: shared hosting imposes an inode cap regardless of how much disk space you have purchased.
This creates a counterintuitive situation that trips up many site owners: you can have gigabytes of available disk space left on your hosting account and still be completely unable to create a new file. The inode limit and the disk space limit are separate constraints that operate independently. A directory containing 50,000 tiny 1KB cache files uses only 50MB of disk space but consumes 50,000 inodes. If your account is at 195,000 inodes but has 8GB of free disk space, you still cannot upload a new image or save a new post until you reduce the file count.
Why shared hosting has inode limits at all
Understanding why this limit exists helps you understand why it matters and why your hosting provider is not simply being arbitrary.
Shared hosting places many customer accounts on the same physical server. Every file operation on that server, whether reading, writing, or checking file metadata, involves the file system. When one account accumulates hundreds of thousands of files, the file system has to manage a much larger index, which increases the overhead for every file lookup operation on the entire server, including operations for other customers’ accounts. At scale, a single account with an extremely high inode count creates a measurable performance drag on the shared environment that affects everyone on the same server.
The inode limit is therefore a fair-use mechanism, not a revenue extraction tool. It protects the performance of the shared environment for all accounts. Providers enforce it through automated monitoring, and many have both a soft limit (where you receive a warning email and backups may be suspended) and a hard limit (where new file creation is blocked and the account may be flagged for review or suspended). HostGator‘s documented structure is a clear example of how this typically works: the soft limit at 100,000 triggers warning notifications, while the hard limit at 250,000 can trigger account review and potential suspension if not addressed.
What actually breaks when the inode limit is exceeded
The symptoms of an exceeded inode limit are wide-ranging and easily mistaken for other problems. Here is a specific list of what breaks and why each one breaks.
New file creation fails: This is the most immediate effect. The moment your account hits the hard limit, the file system refuses to create any new inode. This means you cannot upload a new image, create a new directory, save a draft in WordPress, or generate any file through any mechanism, automated or manual. WordPress will throw a fatal error or white screen if it tries to write to a temporary file or log and cannot. Any plugin that creates files as part of its operation will fail silently or visibly.
Email stops arriving: Each email message stored on the server is one inode. If your hosting plan includes email hosting, new incoming messages cannot be stored once the limit is hit. The messages may bounce back to the sender or queue on the sending mail server waiting to be delivered. This is one of the most damaging real-world consequences because you can miss time-sensitive client messages, account notifications, or customer inquiries without any visible indication on your end that anything is wrong.
WordPress forms and WooCommerce orders fail: Form submissions create temporary session and log files. WooCommerce creates order records and related files. If the inode limit is hit while a customer is placing an order, the transaction may fail partway through, creating a bad customer experience and potentially triggering a payment hold without an associated order record.
Automated backups stop: Both hosting-provided backups and WordPress backup plugins require creating files to store the backup archive. Once the inode limit is reached, no backup can complete. If you were relying on automated backups as your disaster recovery plan, you may not realize they stopped weeks ago until you need to restore something.
Scheduled tasks (cron jobs) stop executing: WordPress and other CMS platforms use cron jobs to run scheduled tasks: publishing scheduled posts, sending newsletters, checking for plugin updates, running WooCommerce order processing. Many of these tasks require writing temporary files. If temp file creation fails due to the inode limit, the cron job fails silently and the scheduled task does not execute.
The hosting control panel itself may show errors: cPanel and other control panels cache and write temporary files as part of their operation. Under an inode limit situation, you may encounter errors within the control panel itself when trying to check file usage or run tools, which can make diagnosing the problem harder.
The most common causes of inode exhaustion on WordPress sites
Knowing the theoretical causes is less useful than knowing the specific WordPress patterns that generate excessive inodes in real hosting environments. These are the most common sources, in order of frequency.
Runaway backup plugins: This is the single most common cause in WordPress environments. Backup plugins like UpdraftPlus, BackWPup, and similar tools create archive files on every scheduled backup. If the plugin is configured to store backups on the server rather than offloading them to external storage (Google Drive, Dropbox, Amazon S3), and if the retention setting is set to keep many copies, the backup folder grows continuously. A backup plugin running daily with 30-copy retention that stores archives on the server will generate 30 compressed archive files per site. Each archive itself may expand into hundreds of individual files depending on the plugin’s compression method. A single misconfigured backup plugin can exhaust 100,000 inodes within weeks on an active site.
Cache plugin file accumulation: WordPress caching plugins generate a separate cached HTML file for each URL on your site. A site with 500 published posts, multiple category pages, tag pages, archive pages, and author pages can have several thousand cached files. If the cache is never cleared and content is published frequently, cached files for old versions of the same URL accumulate alongside the new versions. Popular cache plugins including WP Super Cache, W3 Total Cache, and others store their cache files in /wp-content/cache/, and this directory can grow to tens of thousands of files on active sites.
Accumulated session files: PHP stores session data for logged-in users and form interactions in a /tmp/ directory on the server. On shared hosting, these session files are created automatically and should be cleaned up by the server’s session garbage collection process. If that process is not running correctly, session files accumulate indefinitely. A site with moderate traffic can accumulate thousands of session files over time. Some hosting providers’ shared environments have misconfigured session cleanup schedules that make this problem worse.
Inactive WordPress installations: Many site owners install WordPress to test a theme or plugin, then abandon the installation without deleting it. A default WordPress installation with no content creates several thousand files. An installation that has run for a year with plugins, themes, and cache files can easily have 20,000 to 50,000 inodes. If you are hosting multiple abandoned WordPress installations alongside your active site, they are contributing to your inode count without providing any value.
Accumulated email: On shared hosting plans that include email hosting, every message in your inbox, sent folder, trash, and spam folder is one inode. An email inbox that has never been cleaned and has accumulated 10,000 messages over several years is consuming 10,000 inodes. If you are running multiple email accounts on the same hosting account, multiply this across all inboxes and folders.
Log file accumulation: WordPress, Apache, and PHP all generate log files. Access logs, error logs, and plugin-specific logs can grow into thousands of individual files over time, particularly on sites that have experienced errors that generated repetitive log entries. The /logs/ directory on shared hosting accounts is a common source of excessive inodes that goes uninspected for months.
More hosting intelligence
Step-by-step process to diagnose and reduce your inode count
The following steps address the most common causes in the order that typically produces the fastest reduction in inode count.
Step 1: Check your current inode usage and identify the heaviest directories. In cPanel, your inode usage appears in the right-hand statistics panel labeled File Usage or Inodes. Click on the number or navigate to Files, then Disk Usage to see a breakdown by directory. On hPanel (Hostinger), go to the website Dashboard, then Hosting Plan, then Resource Usage. The goal at this step is to identify which directory is consuming the most inodes before you start deleting anything.
If you have SSH access, the most precise diagnostic command is:
find /home/youraccount -maxdepth 3 -type d | while read dir; do count=$(find “$dir” | wc -l); echo “$count $dir”; done | sort -rn | head -20
This outputs your 20 highest-inode directories with their counts, sorted from largest to smallest. Replace /home/youraccount with your actual account path.
Step 2: Clear your WordPress cache. Navigate to your caching plugin’s settings and use the Clear All Cache button. Alternatively, use cPanel File Manager to navigate to /wp-content/cache/ and delete all contents of that directory. Do not delete the cache directory itself, only its contents. This single step regularly frees 10,000 to 50,000 inodes on active WordPress sites.
Step 3: Fix your backup plugin configuration. Open your backup plugin settings and change the storage destination from local server storage to external storage (Google Drive, Dropbox, or Amazon S3). Then delete all existing backup archives from the server. In cPanel File Manager, look for folders named after your backup plugin (common names include updraftplus, backwpup, backups, wp-backup) inside /wp-content/ and delete their contents. Do not delete the plugin folder itself, only the backup archives. This is frequently the single largest inode reduction available on WordPress sites.
Step 4: Delete session files. If you have SSH access, run: find /tmp -name “sess_*” -type f -mtime +1 -delete. This deletes session files older than one day. If you do not have SSH access, use cPanel File Manager to navigate to the /tmp/ directory and delete any files beginning with sess_.
Step 5: Delete or remove inactive WordPress installations. Use cPanel File Manager to identify subdirectories that contain full WordPress installations you are no longer actively using. Download a backup of anything you want to preserve, then delete the directory entirely. An unused WordPress installation typically frees 5,000 to 30,000 inodes depending on how long it was active and how many plugins were installed.
Step 6: Clean your email inboxes. In your webmail client or email client, empty the trash and spam folders for all email accounts on your hosting account. If you have inboxes with thousands of old messages you no longer need, archive or delete them. If you need to preserve old email, download it to a local client before deleting from the server.
Step 7: Remove old log files. In cPanel File Manager, navigate to the /logs/ directory within your account. Delete access_log and error_log files that are more than a few weeks old. Current log files are still being written to and should not be deleted, but older rotated log files can be removed safely.
Step 8: Delete deactivated WordPress themes and plugins. Deactivated plugins and unused themes in /wp-content/plugins/ and /wp-content/themes/ still consume inodes. Remove any theme or plugin you are not actively using.
Step 9: Verify the reduction. Refresh your cPanel statistics or re-run the SSH command from Step 1. Note that inode counts in cPanel are sometimes cached and may not update immediately. Some providers note that the Resource Usage tool updates on a weekly cycle, so you may need to wait up to 24 hours to see the full reduction reflected in the dashboard.
hosting account exceeded inode limitWhen cleanup is not enough: upgrade or change platforms
If you have completed all the cleanup steps above and your inode count is still persistently high, or if you find yourself doing inode cleanup every few weeks because your site naturally generates many files, the right answer is not more aggressive cleanup. It is an infrastructure change.
Shared hosting inode limits are structural constraints of the shared hosting model. They exist because the shared file system needs to maintain performance for all accounts on the server. If your site legitimately requires more than 200,000 to 250,000 files to function, you have outgrown shared hosting. The appropriate solutions are: upgrading to a higher-tier shared hosting plan that provides a larger inode allocation, moving to a VPS hosting plan where inode limits are either very high or not enforced at the same level, or moving to a managed cloud hosting platform like Cloudways where you have a dedicated server with no shared inode constraints.
VPS hosting from providers like DigitalOcean, Vultr, or through a management layer like Cloudways eliminates the shared inode constraint because your server is not sharing a file system with other customers’ accounts. The Linux ext4 file system used by most VPS providers theoretically supports billions of inodes per volume, making inode limits a non-issue for most workloads. The trade-off is increased cost and increased management responsibility, which is the standard shared-to-VPS migration trade-off.
Before upgrading, confirm that your inode usage is genuinely necessary and not the result of misconfigured plugins. A properly configured WordPress site with a well-maintained caching strategy and off-server backup storage should comfortably operate within a 250,000 inode shared hosting limit for most standard content sites. If you are consistently reaching the limit despite proper configuration, that is a genuine signal that your site’s architecture requires dedicated server resources.
Advanced diagnosis: finding the exact source with SSH commands
If you have SSH access to your hosting account (available on most mid-tier and above shared hosting plans, and on all VPS plans), you can identify the exact source of inode consumption with precision that the cPanel interface cannot match. This is particularly useful when the cPanel disk usage tool shows your inode count is high but does not clearly identify which directory is the primary cause.
To find the top inode-consuming directories in your entire account, run this command after connecting via SSH:
find /home/yourusername -maxdepth 4 -type d -exec sh -c ‘echo $(find “$1” -maxdepth 1 | wc -l) “$1″‘ _ {} \; | sort -rn | head -30
Replace /home/yourusername with your actual home directory path. This command counts the files in each directory up to four levels deep and outputs the 30 directories with the highest file counts, sorted from largest to smallest. Running this takes two to five minutes on a large account and gives you an unambiguous list of where to focus your cleanup effort.
To count the total inodes currently in use across your entire account:
find /home/yourusername | wc -l
This single command gives you the total file count for your account. On shared hosting where the cPanel inode counter updates weekly, this SSH command gives you a real-time number that reflects changes immediately after you delete files. This is useful for verifying that a cleanup action actually reduced the count before you wait for the cPanel dashboard to refresh.
To find and count session files specifically, which are frequently overlooked:
find /tmp -name “sess_*” -type f | wc -l
If this returns a number in the thousands or tens of thousands, session file accumulation is a significant contributor to your inode count and deleting those files (with the -delete flag added to the find command) will produce an immediate reduction.
One important diagnostic note about WordPress backup plugin files: many backup plugins create not just a single compressed archive but a directory structure with multiple files per backup set. A plugin that creates 30 backup sets may actually generate 300 to 3,000 individual files if each set includes separate archives for the database, the uploads folder, the plugins folder, and the themes folder. When you run the inode diagnostic command and see a backup plugin directory with an unexpectedly large file count, open the directory and count the individual files rather than the number of named backup sets shown in the plugin’s dashboard, because those two numbers are often very different.
Preventing inode exhaustion going forward
Once you have resolved an inode limit violation, the following practices prevent recurrence without requiring ongoing manual intervention. Implementing these changes takes less than 30 minutes and eliminates the most common causes of repeated inode exhaustion on WordPress sites.
Configure all backup plugins to store archives externally. Every WordPress site running on shared hosting should have its backup plugin configured to push archives to Google Drive, Dropbox, or Amazon S3, with the delete local copy option enabled. Never store backup archives on the same server you are backing up.
Set your caching plugin to automatically clear old cache files on a schedule. Most caching plugins have a setting for cache expiration that automatically invalidates and removes old cached files. Setting this to a reasonable interval (24 to 48 hours for most content sites) prevents cache accumulation.
Monitor your inode usage monthly. Set a calendar reminder to check your inode usage in cPanel or hPanel once a month. Catching a problem when you are at 150,000 inodes gives you time to address it without urgency. Discovering it for the first time at 249,000 inodes means your site is already compromised.
Delete plugins and themes you are not using immediately rather than leaving them deactivated. The inode cost of a deactivated plugin is identical to an active one from the file system’s perspective.
Keep your email clean. If you host email on your hosting account, set up a regular cleanup routine for spam and trash folders. Alternatively, move your professional email to a dedicated email provider like Google Workspace, where email storage is completely separate from your hosting account’s inode count and scales independently without affecting your web server’s file system.
Sources and references consulted: Hostinger inode documentation, HostGator inode documentation, PHP session files, Apache log files, FileZilla, WordPress backups, Bluehost, VPS hosting options.
