Errors and Raw Access: investigate a failed page with useful evidence

A browser’s error page is only the visible symptom. Web-server errors, access logs and application logs describe different parts of the request. Retention and availability depend on the host.

Follow a single request

1. Note the exact URL, time zone, operation and response code.
2. Open Errors and look for a matching event. A recent-log screen may not include older failures.
3. Review the application’s private logs for the same time. Keep public error display off.
4. Use Raw Access where available to inspect request paths and status patterns.
5. Retest once after a specific correction and compare the new event.

Interpret the evidence

A 404 can be a missing file, wrong root or routing issue. A 403 may involve permissions, authentication or a firewall. A 500 needs its corresponding server or application error; guessing from the code alone can waste time.

Logs may contain IP addresses, paths and submitted identifiers. Store downloads privately and redact sensitive data before asking for help. Do not publish logs in the website’s root. If an error repeats rapidly, investigate its cause and configure reasonable retention instead of turning off all logging. A missing event may mean you are checking the wrong server or log source.