How do I diagnose a PHP website returning HTTP 500?
HTTP 500 identifies a server-side failure but does not identify its cause. It may be a PHP exception, a syntax error, a failed dependency or an invalid application setting. Use the failing request time to find the first relevant error and keep detailed diagnostics out of the public response.
Before you start
- The exact failing request and incident time.
- Authorised access to application and web-runtime logs.
Instructions
1. Locate the first relevant error
Inspect the configured application log and PHP/FPM or Apache error log for a narrow time interval. Later failures can be consequences of the initial error. Redact credentials, tokens and customer data before sharing excerpts.
2. Lint the changed PHP file
Use the PHP major/minor version that the web application actually runs. The path below is illustrative; lint the specific deployed file implicated by the log or recent change.
php -v
php -l /var/www/app/public/index.phpReports CLI PHP and checks syntax without executing the script. A successful lint does not test includes, database queries or application logic.
3. Compare runtime configuration and dependencies
CLI and web PHP can load different configuration files and extensions. Establish which FPM pool or Apache handler serves the site before comparing the relevant runtime settings.
php --ini
php -mShows CLI configuration paths and loaded modules for comparison; these results alone do not describe the web runtime.
Check the result
- The logged root cause is corrected in the affected application, the failing request succeeds and no new matching fatal error appears.
- Public error output remains appropriately limited.
Troubleshooting
- Lint passes but the site still returns 500
- Investigate the actual exception, runtime version, permissions and dependency error. Syntax validation cannot prove a request will execute successfully.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.