PHP and MySQL
How to debug a PHP 500 error safely
Correlate request logs, PHP-FPM errors and recent changes without displaying sensitive stack traces to visitors.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Keep public error display off in production and correlate the failing request with web-server, PHP-FPM and application logs. Reproduce the exact route, method and input safely, check the first error rather than the cascade, and link it to the latest deployment or configuration change.
What this means in plain English
A 500 response means the server could not complete the request, but the safe public page should not reveal file paths, passwords or a full error trace. Useful details belong in private logs with a time and request identifier.
Follow the request through the proxy, web server, PHP-FPM and application logs. Start with the first error, because one failure can create many later messages. Compare the time with recent code, configuration or permission changes.
Where is the useful error evidence?
| User response | Generic message plus request identifier |
|---|---|
| Private evidence | Timestamped exception, stack and release |
| Reproduction | Exact route and safe representative input |
A simple example
A form returns 500 after a deployment. The request ID leads to a PHP log showing a missing extension, while later messages show unrelated cleanup failures. Installing the required extension in staging and redeploying fixes the first cause without exposing details to visitors.
What to do, step by step
1. Capture time and request identifier.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on user response: generic message plus request identifier. Write the result down so you can compare it later.
2. Inspect proxy, web-server, FPM and app logs in order.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Check syntax, permissions, extensions and environment changes.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Verify the repair through the original path.
Finish by checking the result against reproduction: exact route and safe representative input. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Collect evidence before restarting when it is safe. A restart may clear a full worker or temporary problem and remove the state that explained it.
Common mistakes and how to avoid them
Turning display_errors on publicly.
This gives a misleading or unsafe result because it leaves out user response. A better approach is to capture time and request identifier, then check the result before making the change permanent.
Restarting before collecting evidence.
This gives a misleading or unsafe result because it leaves out private evidence. A better approach is to inspect proxy, web-server, fpm and app logs in order, then check the result before making the change permanent.
Fixing a later cascade message instead of the first failure.
This gives a misleading or unsafe result because it leaves out reproduction. A better approach is to check syntax, permissions, extensions and environment changes, then check the result before making the change permanent.
Words explained
- PHP
- The programming language that runs the server-side part of many websites and applications.
- PHP-FPM
- A common service that keeps PHP workers ready to handle web requests.
Quick checklist
- Capture time and request identifier.
- Inspect proxy, web-server, FPM and app logs in order.
- Check syntax, permissions, extensions and environment changes.
- Verify the repair through the original path.
Common questions
What is the simple answer?
Keep public error display off in production and correlate the failing request with web-server, PHP-FPM and application logs. Reproduce the exact route, method and input safely, check the first error rather than the cascade, and link it to the latest deployment or configuration change.
What should I check first?
Start with user response: generic message plus request identifier. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Capture time and request identifier. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Turning display_errors on publicly. Avoiding that one mistake makes the rest of the comparison much more trustworthy.