FaultForge

500

500 Internal Server Error

Find the cause of a 500 Internal Server Error by checking logs, recent deploys, plugins, PHP failures, permissions, and rollback options.

Start here

Site owner path Roll back a recent risky change Check public impact, recent changes, and the first layer that returned the error. Server operator path Find the first server-side error Use logs, upstream health, and rollback evidence before changing configuration.

Quick Answer

Reproduce once, capture the timestamp and URL, then check the application, PHP, web server, and deployment logs. Do not keep refreshing or changing settings before you find the first specific error.

Why 500 is a catch-all

A 500 response tells you the server hit an unexpected condition while processing the request. It does not identify the root cause by itself. Use timestamps, request IDs, and matching access/error log lines before changing code, plugins, permissions, or server settings.

Visitor vs site owner actions

A visitor can refresh, retry another network, or report the URL and timestamp. A site owner should preserve the failed response, check the access and error logs, review recent deploys or plugin updates, then roll back the smallest recent change if the logs point to it.

Common log phrases

Log phraseLikely meaningNext page
PHP Fatal errorPHP, plugin, theme, or app crashWordPress 500 checks
permission deniedFile ownership or permission issueLog triage guide
prematurely closed connectionApp process or upstream issue502 diagnosis if a proxy is involved

Diagnosis

Symptoms

  • One route, form, admin page, or full site returns 500.
  • Recent code, plugin, dependency, permission, or config changes happened nearby.
  • Logs mention fatal errors, exceptions, memory limits, permission denied, or database failures.

Common causes

  • Application exception or PHP fatal error.
  • Bad deployment, missing dependency, or incompatible runtime version.
  • File permission, rewrite, or environment variable mismatch.
  • Database connection, query, or migration failure.

Diagnostic Checklist

  1. Record URL, timestamp, user action, and request method.
  2. Check application and web server error logs for the same timestamp.
  3. Compare recent deploys, config edits, and dependency changes.
  4. Roll back the smallest likely change only after saving evidence.

Fixes

Find the first server-side error

  • 10 minutes
  • Risk: low
  • Developer
  • Application, server logs

Turn a generic 500 into a specific file, route, or dependency failure.

  1. Open application, runtime, and web server error logs.
  2. Search the failing timestamp and URL path.
  3. Copy the first exception or fatal error line.
  4. Map that line to the deployment, plugin, config, or dependency that owns it.
Expected result

The 500 is tied to a specific failing component.

If it failed

If logs are empty, verify logging configuration and reproduce once with correlation IDs if available.

Verify

Reload the URL after the targeted fix and confirm the error line stops.

Rollback

Revert unrelated changes made while diagnosing.

Was this fix useful?

Roll back a recent risky change

  • 15 minutes
  • Risk: medium
  • Site owner
  • Deployment, CMS, config

Reduce outage impact when the error clearly follows a recent change.

  1. Identify the smallest recent change linked to the failing route.
  2. Capture current state and logs before rollback.
  3. Use the normal deploy, hosting, or CMS rollback path.
  4. Clear only the caches touched by the change.
Expected result

The failing route recovers or reveals a narrower error.

If it failed

If rollback does not help, restore the captured state and continue log analysis.

Verify

Test the failing route and a known-good route.

Rollback

Record the version or setting restored.

Was this fix useful?

Platform notes

For WordPress, check plugins, themes, PHP errors, and database health. For nginx, a backend application 500 is different from an nginx-generated 502 upstream failure.

FAQ

Can visitors fix a 500 error?

Usually no. Visitors can retry later or report the exact URL, but the fix belongs to the site owner or server operator.

Is 500 the same as 502?

No. A 500 is an internal server or application failure. A 502 is a gateway failing to get a valid upstream response.

Review notes

Last reviewed
2026-05-05
Reviewed by
FaultForge Editorial Team, Web operations reviewer
Tested on

HTTP status checks, access and error log review, server response headers, recent deployment review, and safe rollback verification.

Sources