HTTP 500 is a generic server-side failure. The useful diagnosis is in the request-correlated application, PHP/runtime, web-server or dependency error, so capture the failing request and logs before changing configuration or enabling verbose errors publicly.
Step-by-step checks
Record the exact URL, method, request/correlation ID and timestamp, then reproduce once while collecting the relevant application and web-server error logs.
Identify whether the failure occurs in application code, runtime/PHP, database, filesystem, API dependency or reverse-proxy integration rather than treating 500 as one root cause.
Compare recent deployments/configuration changes and verify required secrets, files, permissions and dependency endpoints are available to the application identity.
Use a staging/local diagnostic mode or protected logs for stack traces; do not expose detailed production exceptions to unauthenticated users.
Useful verification commands
Use commands only on systems you administer and capture the read-only output before making a configuration change.
curl -I https://example.com/failing-path
curl -vk https://example.com/failing-path
How to validate the result
The original request must complete successfully after the identified server-side cause is corrected, and error monitoring should show no recurring matching exception.
Evidence to keep
Keep request ID/timestamp, sanitized stack trace or error line, application/runtime versions, recent change reference, dependency result and successful retest.
Frequently asked question
Should I enable display_errors on a production site to troubleshoot HTTP 500?
No. Capture detailed errors in protected logs or a staging environment. Public stack traces can reveal paths, secrets, queries and internal implementation details.