Read website error logs

Find the logs

Every page that fails points at a log. Which log it names depends on the layer that caught the failure:

Read the entry

An error log line is dense but ordered. nginx:

[error] 10443#0: *57 upstream timed out (110: Connection timed out)
while reading response header from upstream,
client: 203.0.113.21, server: www.example.com, upstream: "fastcgi://unix:/var/run/php-fpm.sock"

Decode it right to left: the client IP is not the cause, the upstream is. The worker and socket name sit to the right of upstream:, so a socket failure names the PHP-FPM pool, not a PHP file. Now open the PHP log next to it.

A PHP entry:

PHP Fatal error:  Uncaught TypeError: implode(): Argument #1 ($pieces) must be of type array
in /home/user/public_html/wp-content/themes/theme/functions.php:212

The reading order for that one:

1. Fatal error vs Warning vs Notice. Fatal kills the request; warnings rarely stop the page.
2. The line names the file: functions.php:212 says the theme file at line 212.
3. The message names the function argument problem. It does not say the theme is old; it says a plugin passes the wrong type to implode.

The log says more than errors

• Requests that time out show up as upstream timed out; the page may look fine but crawl slowly, and the log callout points to the proxy, not the app.
• Disk-full errors arrive as No space left on device in the write path, before the page ever errors. See server disk full.
• Database lines name the query and the error message the driver raises; they pair with the database connection error checklist.

Work the entry

1. Confirm the error is live: reload the page that failed and re-check the log for a fresh entry; stale entries run for minutes after a fix.
2. Open the named file and the named function. Fix the input, not the output.
3. Search the upstream name in the environment spec, not the public docs: the socket path is yours.
4. After a change, tail the log and reload the page; one live line that turns from error to nothing is the proof.

Log hygiene

• Never leave PHP error_reporting(E_ALL) with display errors enabled in production; write to a file instead. One fatal that renders a full file path into a public page is a leak.
• Rotate logs so a full disk never stops the site (logrotate works for nginx, Apache and PHP-FPM).
• Keep logs outside the web root where browsers can reach them; a logs/ folder inside the document root is a disclosure risk.

When to involve a professional

If the error log is healthy (no new lines) and the page still fails, the log was rotated, truncated, or written to a path you don't own (site load balancer, edge, or managed platform). Ask the host for the request log view; that is the layer the panel keeps for you.