5 things to check before your PHP platform goes down in production

Production incidents rarely come out of nowhere. In my experience, most of them are preceded by warning signs that nobody was watching for — quiet problems accumulating in the background until something finally gives.

When I take over support for an established PHP platform, I run through a set of checks before anything else. Here are the five most important ones — and what I commonly find.

1. Disk space

This sounds too simple to be worth mentioning. It's the one that bites the most teams.

A server running low on disk space doesn't usually give you much warning before things start going wrong. Log files stop writing. File uploads fail silently. Database operations start throwing errors. In the worst case, the entire application grinds to a halt.

Common culprits: application log files that have never been rotated, session files accumulating over years, database backups filling a local disk, or — as I found on one recent platform — a plugin bug causing a security log to grow indefinitely to 674 MB before anyone noticed.

Check it now. Set up an alert if you can. It should never be a surprise.

2. Error logs

If you haven't looked at your PHP error logs recently, you should. Most platforms have errors in them — often lots of them. The question is whether those errors are noise (deprecation notices, third-party warnings) or signal (real issues that will become failures).

The dangerous state is when logs are so full of noise that nobody reads them anymore. That's when the errors that actually matter — memory exhaustion on a PDF render, a database connection failing intermittently, a critical third-party API returning errors — get buried.

Clean up your logging configuration so you're only surfacing actionable errors. Then read them.

3. Backup status

Not just whether backups are configured — whether they're actually running, going somewhere accessible, and have been tested. I've seen platforms where backups were configured but silently failing for months, and platforms where backups were running but sending to a third-party account that nobody could access.

The specific questions to answer:

• When did the last backup actually complete successfully?

• Where is it stored, and can you access it right now?

• Have you ever restored from it to verify it works?

• Does the backup include both files and database?

If you can't answer all four of those, your backup strategy has gaps.

4. PHP version and dependency currency

Running an old version of PHP isn't just a security risk — older versions have known performance and memory issues that affect production behaviour. PHP 7.4 reached end of life in 2022. If you're still running it, you're not receiving security patches.

Similarly, outdated Composer packages and plugins accumulate risk silently. Libraries often contain bug fixes in newer versions that directly affect production stability — memory efficiency improvements, PDF rendering fixes, database driver patches. An out-of-date dependency that's causing intermittent failures might have a fix in the changelog that nobody's looked at.

Run `php -v` on your server. Check your `composer.lock`. Know what you're running.

5. Memory limits and timeout configuration

PHP's default configuration is designed for general-purpose use. If your application does anything memory-intensive — generating PDFs, processing images, running large data exports, importing spreadsheets — the defaults may not be appropriate for what you're actually asking the server to do.

The classic symptom is intermittent failures on specific operations that involve heavier processing. Works fine on small inputs, fails on larger ones. Often dismissed as a one-off until it happens enough times that someone investigates. Usually fixable in minutes once diagnosed — but only if you know to look.

Check your `php.ini` or server configuration: `memory_limit`, `max_execution_time`, `upload_max_filesize`, `post_max_size`. Make sure the values reflect what your application actually needs.

The common thread

All five of these issues share a characteristic: they're invisible until they cause a problem, and they're trivial to catch with regular review. A platform that's never had a proper infrastructure audit is almost certainly carrying at least one of them.

The good news is that none of them require major work to fix. Finding them is the hard part — which is why they accumulate unnoticed in the first place.

Want someone to run these checks on your platform?

If your PHP platform hasn't had a proper infrastructure review, I'm happy to take a look. It's usually a short piece of work that gives you a clear picture of where you stand. Get in touch and we'll have a conversation about it.