A while ago, I wrote a brief guide to common WordPress Multisite errors on Google Cloud Platform. It covered some of the problems we’d encountered running WordPress on Google Cloud, from broken permalinks to database connections and SSL configuration.
A few years later, the same infrastructure has presented a few more problems worth documenting.
1. Running out of VM disk space
Our Google Compute Engine VM has a relatively small root disk, around 10GB. Over time, available space became increasingly constrained.
To investigate, we started with:
df -hThen identified which directories were consuming the space:
sudo du -h -x --max-depth=1 /var | sort -hThe interesting findings were:
| Directory | Size |
|---|---|
/var/lib | 3.6GB |
/var/www | 1.1GB |
/var/log | 857MB |
/var/cache | 134MB |
Drilling into /var/lib revealed that /var/lib/snapd accounted for approximately 3.1GB — considerably more than the MySQL directory, which was around 190MB.
sudo du -h -x --max-depth=1 /var/lib | sort -hThis helped identify Snap packages and their retained data as a major contributor to disk consumption, alongside accumulated logs.
The important distinction is between identifying large directories and safely deleting them. Snap revisions, logs and caches each have their own cleanup mechanisms; deleting application directories indiscriminately can cause more problems than it solves.
The lesson: when disk space is running low, investigate by directory before changing anything. The largest consumer isn’t necessarily WordPress itself.
2. No space left on device — but the disk wasn’t full
A later incident produced a similar symptom, but with a completely different cause.
The VM had available disk space, yet services were failing and reporting filesystem errors.
This time, the important command was:
df -iIt showed that we’d exhausted 100% of the filesystem’s approximately 1.29 million inodes.
An inode represents a filesystem object, such as a file or directory. You can have free gigabytes but still be unable to create new files if all available inodes are occupied.
The culprit was more than a million PHP session files in /tmp.
After removing expired sessions, inode usage fell dramatically. But we also needed to stop the problem recurring.
Our LiteSpeed PHP installation had automatic session garbage collection disabled, and Ubuntu’s standard PHP session cleanup wasn’t covering the relevant files.
We added an hourly cron job to delete PHP sessions older than seven days:
17 * * * * root /usr/bin/find /tmp /var/lib/php/sessions -maxdepth 1 -type f -name "sess_*" -mmin +10080 -deleteThe retention period was deliberately generous for our WooCommerce installation, although the appropriate lifetime depends on the application.
The lesson: monitor inode usage as well as disk capacity. They’re different resources, and exhausting either can bring down a server.
3. Error establishing a database connection
We also experienced a more familiar WordPress error: the application couldn’t connect to its database.
Our database runs on Google Cloud SQL, separate from the Compute Engine VM. Testing connectivity showed TCP timeouts, while attempting to restart the database returned an internal error.
Restarting the VM didn’t resolve anything.
Eventually, the cause became clear: a wider Google Cloud outage in the London (europe-west2) region, affecting Cloud SQL and other services.
There wasn’t a local configuration change that could fix the underlying regional failure.
The lesson: check your cloud provider’s service health before assuming the problem is yours. Restarting healthy components during an upstream outage can introduce additional complications without addressing the cause.
4. Critical PHP vulnerabilities
On 21 October 2026, PHP published a security advisory covering two critical remote code execution vulnerabilities: CVE-2026-109618 and CVE-2026-109619.
Our OpenLiteSpeed installation was running PHP 8.1.27, an unsupported release.
Fortunately, the LiteSpeed repository already offered the patched PHP 8.4.27 release.
We installed PHP 8.4 alongside PHP 8.1, including the required WordPress and WooCommerce extensions, then compared configuration settings. The new PHP installation had lower memory and upload limits, so we adjusted them before switching.
The active PHP handler was configured in:
/usr/local/lsws/conf/httpd_config.confWe changed:
path lsphp81/bin/lsphpTo:
path lsphp84/bin/lsphpAfter validating the OpenLiteSpeed configuration and restarting the service, we checked the executable paths of the running PHP workers:
for pid in $(pgrep -x lsphp); do
echo "PID $pid: $(sudo readlink -f /proc/$pid/exe)"
doneAll the reported workers were running PHP 8.4, confirming the new handler was active. Application-level compatibility testing remained the final step.
The lesson: installing a new PHP version doesn’t necessarily mean your website is using it. Verify the actual runtime serving requests, not just the command-line version.
What I’ve learnt
These incidents were quite different, but the approach to resolving them was similar.
Start by understanding which part of the system is failing. Measure before making changes. Distinguish symptoms from causes. Check whether a problem originates in your application, your VM or the cloud provider itself.
And make small, reversible changes, verifying each one before moving on.
WordPress on Google Cloud is perfectly capable of running reliably, but even a relatively simple installation accumulates operational complexity over time. The more you understand the underlying infrastructure, the easier it becomes to work out what has actually gone wrong.
