Use the web-server log viewer while reproducing a specific error to connect the browser symptom with the server’s evidence. Record the exact URL and time so unrelated background traffic does not distract from the failing request.
IN THIS ARTICLE
What you need before you begin
Confirm the affected domain and server timezone. Avoid placing passwords or personal data in test URLs, and treat downloaded logs as potentially sensitive because requests can include identifiers or query strings.
01 Follow SiteWorx web-server logs during a reproducible error
- Open Administration > Logs > Web Server Logs and continue to the log options.
- Choose the relevant transfer or error log, including the SSL variant where appropriate for an HTTPS request.
- Select a useful line count and ordering. Enable follow behaviour if available while you reproduce one controlled request.
- Compare the request time, path, status and error text. Check application logs separately if the web-server entry only reports a generic upstream or application failure.
- Save the smallest relevant excerpt for support, including timezone and reproduction steps, then remove unnecessary personal data before sharing it.
Confirm the expected result
You should be able to identify the request and determine whether the failure is at the web server, runtime or application layer. A successful transfer entry can still accompany an application-level problem.
Troubleshoot unexpected results
On LiteSpeed, the SiteWorx error-log viewer may be empty because LiteSpeed uses its own server log location. Ask the provider to inspect that layer rather than assuming no error occurred. Log rotation also means older events may be elsewhere.
Should I post the entire log publicly?
No. Share a relevant sanitised excerpt through the support channel. Full logs can expose customer paths, source addresses, tokens or other details unrelated to the fault.