Where can I find the log files?
You can access the log files for your web space via FTP. You will find the log files in the “/logs” folder, at the same level as “/html”.
If there are no logs in the corresponding folder, please check the PHP settings of the domain in the client interface and ensure that “error_reporting” is enabled for the domain. For more information, see the support article “How can I display PHP errors?”.
What you can find in /logs and when to use each log
The /logs directory in your webhosting package contains server-generated log files related to your website’s activity. These logs are created automatically and are separate from your website files in /html. Their purpose is to help you understand how requests are handled and why errors may occur.
Typically, you will find:
- Access logs record incoming requests, including timestamps, requested URLs, HTTP status codes, and client IP addresses. These are useful for confirming whether requests reach the server and how the server responds.
- Error logs: record server- or application-level errors, such as PHP fatal errors, warnings, or permission issues. These are the primary sources for diagnosing “white pages,” broken scripts, or failed requests.
- Domain-specific logs: in setups with multiple domains, logs may be separated by domain to help you isolate issues.
Use access logs to confirm traffic and response behavior, and error logs to identify why something failed. Starting with the correct log saves time and avoids guessing.
Quick reading guide: the 5 things to check first in log files
Log files can be long and overwhelming. A focused approach helps you find relevant information quickly without reading every line.
Start with these five checks:
- Timestamp: Locate entries that match the exact time you triggered the issue in your browser.
- HTTP status codes: look for repeated 500, 403, or 404 responses. These often indicate configuration or application problems.
- Error messages: in error logs, scan for fatal errors, uncaught exceptions, or repeated warnings tied to a specific file path.
- Repeated patterns: the same error appearing multiple times usually indicates a single misconfiguration or a broken script.
- Requested URL or script: identify which page or endpoint is failing so you know where to focus.
By narrowing the scope to a specific time window and pattern, you can usually identify the root cause quickly without deep knowledge of servers.
Privacy and security considerations when handling logs
Log files can contain sensitive information. Even if they are primarily technical, they often include IP addresses, URLs with query parameters, and internal file paths. In some cases, they may indirectly contain personal data or security-relevant details.
When handling logs:
- Limit access to staff who actually need them.
- Avoid sharing full logs publicly or via unsecured channels.
- Redact where appropriate before forwarding logs, especially if they contain user identifiers or tokens in URLs.
- Store logs temporarily and delete them when they are no longer needed for analysis.
If you share logs with support or third parties, send only the relevant excerpts and time range. This reduces exposure and speeds up diagnosis.
Best practices for collecting logs for support
When you contact support, well-prepared log excerpts significantly reduce resolution time. Support teams usually do not need complete log histories—only the relevant context around the issue.
Recommended approach:
- Reproduce the issue, then immediately note the date and time.
- Extract log entries from a short time window around that moment (for example, 5–10 minutes).
- Include both access and error log entries if available.
- Do not modify the log lines themselves; copy them as-is.
- If multiple domains or scripts exist, clearly state which domain and URL you were testing.
This structured collection makes it easier to correlate your actions with log output and helps support focus on the actual problem instead of requesting additional information.