The short version
- 01Record the failing URL, action, time and displayed error identifier.
- 02Check the service's status notice before trying the page again.
- 03Confirm the result before repeating a purchase or other state-changing submission.
- 04Match the failure to application, server or edge-function logs.
- 05Correct the exception or configuration supported by the logs and recent changes.
- 06Verify the original operation through the public site after the fix.
Raw message
500 Internal Server Error
Likely causes
- An unhandled application exception prevents the request from completing.
- Server configuration or file permissions prevent normal processing.
- The application runs out of memory or cannot reach a required database.
- A deployed edge function fails while processing the request.
The code does not identify the broken component
500 is a general response to an unexpected server condition. It does not identify a specific plugin, database or line of code. MDN lists possibilities such as unhandled exceptions, configuration problems, permissions and memory exhaustion.
Our first diagnostic split is scope: does every request fail, or only one route or action? That comparison narrows the investigation, but a single failing input still needs a server-side explanation. A status number is not a substitute for the corresponding error log.
If you are using the affected website
Keep the page address, approximate time and any error identifier, then check the service's status notice. If the failure persists, send those details to support with the action that triggered it. A visitor generally cannot repair the server exception.
If the error follows an order or other write, inspect the resulting record before resubmitting. An error response does not establish that no side effect occurred. Use the site's supported recovery process when the outcome is uncertain.
If you operate the site
Cloudflare documents database-connection failures as one origin-side example and runtime exceptions in Workers as another. Inspect the relevant origin or Worker logs rather than assuming all 500 responses came from the same place.
Our recommended sequence is to correlate the request with the earliest relevant exception, compare recent code and configuration changes, and reproduce the failing action with non-sensitive test data. If a recent release is implicated, use the project's normal rollback or correction procedure.
Apply the smallest change supported by the evidence. Verify the formerly failing route and a normal route through the public serving path, then confirm that the corresponding errors stop appearing. Keep detailed diagnostics in operator logs while giving visitors a useful error identifier and recovery message.
Sources and review notes
Checked on . Based on MDN, Cloudflare and HTTP retry semantics. The scope comparison and repair sequence are editorial guidance; server logs determine the actual cause.