Diagnosing a WordPress HTTP 500 Incident

An agency WordPress website on an Ubuntu Server VPS starts returning HTTP 500 responses after a plugin update. The administrator says the dashboard is unavailable and important functionality may be affected. The investigation checks the web server, PHP-FPM, the WordPress plugin state and the application logs to find the cause. The goal is to restore service safely and document evidence anyone can verify.

The example environment is an Ubuntu Server 22.04 LTS VPS running Nginx, PHP-FPM and MariaDB, with a WordPress agency site on top. The tools are SSH, curl, systemctl, journalctl, WP-CLI and the Nginx and PHP logs. The PHP version has to be confirmed on the actual server.

The reported symptoms are:

• The browser shows "500 Internal Server Error".
• It began after a plugin update, according to the site administrator.
• The WordPress dashboard may be unavailable.
• It happens in every browser, which suggests it is not a local cache problem.

An HTTP 500 is a symptom, not a diagnosis. The timing of a plugin update is a lead to investigate, not proof that the plugin caused the outage.

1. Triage firstRecord the time, the affected URL, the exact HTTP response, any recent changes, and how much is affected. Check whether the homepage, wp-admin and the business-critical workflows all fail. Capture the logs before making more than one change.
2. Collect evidence with read-only commandsNothing here changes the server, so it is safe to run first.
   Read-only diagnosticsCopy

   # Confirm the response from the affected site
   curl -sS -D - -o /dev/null https://example.com/
   
   # Check service status (adjust the PHP-FPM service name to the installed version)
   sudo systemctl status nginx php8.1-fpm mariadb --no-pager
   
   # Validate the Nginx configuration
   sudo nginx -t
   
   # Inspect recent Nginx errors
   sudo tail -n 100 /var/log/nginx/error.log
   
   # Inspect PHP-FPM logs, if configured at this path
   sudo tail -n 100 /var/log/php8.1-fpm.log
   
   # Inspect the PHP-FPM service journal
   sudo journalctl -u php8.1-fpm --since "30 minutes ago" --no-pager
   
   # From the WordPress directory, inspect plugin state
   wp plugin list --path=/var/www/example.com/public_html

3. Read the error carefullyNginx may record an upstream PHP error like the one below. Exact messages vary with the PHP version, the Nginx setup and the logging settings.
   Illustrative log excerpt (not real client evidence)Copy

   2026/10/15 14:23:17 [error] 1842#1842: *1024 FastCGI sent in stderr:
   "PHP message: PHP Fatal error: Uncaught Error: Call to undefined function
   vendor_extension_required_function() in
   /var/www/example.com/public_html/wp-content/plugins/example-extension/includes/feature.php:312"
   while reading response header from upstream, client: 203.0.113.24,
   server: example.com, request: "GET / HTTP/1.1",
   upstream: "fastcgi://unix:/run/php/php8.1-fpm.sock"

   This example suggests PHP tried to call a function that was not available. It does not prove a WooCommerce-specific incompatibility. The real function, file, plugin version, dependencies and stack trace must be confirmed before naming a root cause. PHP application errors may also be logged only through Nginx or a dedicated PHP log, depending on how logging is set up.
4. Find the root cause
   • Match the first 500 response against the reported update time.
   • Identify the first relevant fatal error and its file and line.
   • Work out which plugin or theme owns the failing file.
   • Check that plugin's requirements and release notes against the installed WordPress and PHP versions.
   • Reproduce the failure on a staging or disposable copy when possible.
   • Isolate the suspected component only after the evidence is saved and the action is safe.
   If the evidence points to a missing PHP extension, bad permissions, a database problem or a PHP-FPM setting instead, that cause gets investigated instead.
5. Fix it with the smallest safe changeChoose the least disruptive fix for the confirmed cause. That might be updating the extension to a compatible release, rolling back to a known-good version, installing a documented dependency, or correcting one specific setting or permission. Before touching production, take a verified backup or snapshot and note the current plugin version. If a plugin has to be switched off, think about what it affects (checkout, forms, memberships, bookings). Avoid broad recursive chown or chmod commands as a shortcut.
6. Verify the result
   • Repeat the same HTTP request and confirm the expected status.
   • Test the homepage, wp-admin and the workflow that was broken.
   • Check the Nginx and PHP-FPM logs for new relevant errors.
   • Confirm the database and required services are healthy.
   • If a reload or restart was needed, confirm the fix survives it.
   • Record timestamps and sanitised command output.
   Quick response checkCopy

   curl -sS -o /dev/null -w 'HTTP %{http_code}\n' https://example.com/

   A 200 response alone does not prove every WordPress feature works, so the broken workflow itself gets tested.

Preventing a repeat: keep tested backups and a written recovery procedure, test high-risk plugin updates on staging where practical, check plugin, WordPress and PHP compatibility before deploying, monitor availability and the relevant error logs, and keep a record of the incident timeline, cause, fix and verification.

Throughout, the client hears about it in plain words. A sample update:

We identified a server-side error affecting the WordPress site and are investigating the relevant application and PHP logs. We will confirm the underlying cause before making a targeted change. After the fix, we will test the site and the affected workflow, then provide a summary of the cause and preventive recommendations.

This case shows the workflow I follow: confirm the impact, collect logs, connect the failure to recent changes, isolate the root cause, apply a controlled fix, and verify recovery.