Find the failing WordPress layer and restore service with the smallest supportable change.
HTTP 500 means the server could not complete the request; it does not identify the cause. The useful investigation correlates one failing request with server and application evidence, then isolates configuration, resources, code, database, or upstream dependencies.
Measure scope and timing
Record affected URLs and methods, anonymous versus logged-in state, status, response headers, time, request identifier when available, and the last known good request. Determine whether static files, PHP health checks, admin, API, cron, and unrelated applications on the account work.
Check evidence in risk order
- Hosting status, disk, memory, process, and database availability
- Web-server, PHP, WordPress, and security logs for the request time
- Recent deployment, update, PHP, rewrite, permission, or secret change
- Syntax and configuration validity through supported tools
- Plugin, theme, custom-code, and external-call isolation in staging
- Known-good rollback with current-data protection
Interpret common patterns carefully
| Pattern | Possible layer | Useful evidence |
|---|---|---|
| All PHP fails | Runtime, server, limits | Host status and PHP logs |
| Only WordPress fails | Configuration, code, database | WordPress and fatal logs |
| One route fails | Template, data, integration | Request-specific trace and inputs |
Restore service without losing the cause
- Capture logs before rotation or retry noise.
- Resolve platform or capacity failure first.
- Validate configuration and recent change artifacts.
- Roll back the smallest evidenced release unit.
- Test critical and adjacent workflows.
- Preserve root-cause notes before clearing temporary logs.
Do not trade one outage for another
- Replacing rewrite files without saving current rules
- Changing permissions broadly to make errors disappear
- Disabling security controls without a bounded test
- Restoring the database when only files changed
Create a durable corrective action
Tie the event to a monitored signal, release check, resource threshold, dependency timeout, configuration validation, or recovery procedure. Assign an owner and due date. A good post-incident record distinguishes confirmed cause, contributing conditions, observations, and untested hypotheses.
Continue with the next decision
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- WordPress debugging documentation Official WordPress methods for capturing debug information while avoiding uncontrolled public display.