Check access and error logs for HTTP failures
Learn how to inspect access logs, error logs, status codes, timestamps, upstream failures, and recent changes during HTTP outages.
When to use this guide
Use this guide when a page returns 404, 500, 502, or another HTTP failure and you need evidence before changing code or configuration. Logs are most useful when you have the exact URL, timestamp, timezone, user action, and visible status code.
Access needed
You need one of the following: hosting-panel log viewer, SSH access, container logs, cloud log explorer, or developer access to application logs. Read-only access is enough for the first pass.
Before you start
- Reproduce the error once and note the timestamp with timezone.
- Copy the full URL, method if known, request ID, user account or IP if safe, and the visible status code.
- Do not restart services until you have captured the first matching log line.
Common log locations
| Layer | Common locations | What to look for |
|---|---|---|
| nginx access | /var/log/nginx/access.log | Status code, path, upstream response time |
| nginx error | /var/log/nginx/error.log | Upstream failures, missing files, permission errors |
| Apache | /var/log/apache2/error.log or /var/log/httpd/error_log | PHP errors, rewrite problems, permission errors |
| PHP-FPM | /var/log/php-fpm/error.log or pool-specific logs | Worker crashes, memory errors, slow scripts |
| WordPress | wp-content/debug.log | Plugin, theme, or PHP fatal errors |
Step 1: Match the access log
Find the request in the access log first. This confirms the server received the request and tells you the response code emitted by that layer.
grep "05/May/2026:14:32" /var/log/nginx/access.log | grep "/checkout"Expected output is a line that contains the URL path and a status code such as 404, 500, or 502. If there is no access log entry, check DNS, CDN, firewall, load balancer, or whether you are looking at the wrong host.
Step 2: Match the error log
grep "14:32" /var/log/nginx/error.log
grep "Fatal error" wp-content/debug.logExpected output is a nearby line that explains the failure. For example, open() ... failed (2: No such file or directory) points toward a 404 route or file problem. PHP Fatal error points toward application code, plugin, or theme failure. connect() failed while connecting to upstream points toward a 502 gateway path.
Common phrases and next action
| Phrase | Likely meaning | Next path |
|---|---|---|
GET /old-url 404 | Missing route, page, asset, or redirect target | 404 Not Found |
PHP Fatal error | PHP, WordPress plugin, theme, or app crash | 500 diagnosis |
permission denied | File ownership or mode blocks read/execute | Check deployment user and permissions |
connect() failed | Upstream service or socket unreachable | nginx 502 |
upstream timed out | Slow or overloaded upstream | Trace 502 layers |
Verify
After a fix, repeat the same request and confirm the access log shows a successful status, usually 200, 301, or 302 depending on the intended route. Also confirm the old error phrase stops appearing for the same URL.
Rollback or escalate
If logs point to a recent deploy, restore the smallest changed file, plugin, route, or config. If logs are unavailable, send the host or developer the URL, exact timestamp, timezone, visible status, request ID, and the latest matching access/error log snippets. Do not send passwords, cookies, private tokens, or full customer data.
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.