How to Find Error Logs for a Broken Website

If a website suddenly stops loading, shows a blank page, returns a 500 error, or behaves inconsistently after a change, the fastest way to identify the cause is usually through the error logs. On most hosting platforms, logs capture the exact PHP, Apache, application, database, or permission-related message that explains why the site failed.

This guide explains how to find error logs for a broken website in a hosting or control panel environment, including common log locations, how to use Plesk, what to look for in Apache and PHP logs, and how to interpret the most common errors. It is written for managed hosting users, website owners, and support teams working on EU hosting accounts with DNS, email, and application-related issues.

Why error logs matter when a website is broken

Error logs are the first place to check when a site stops working. A browser only shows the result of the problem, while the log shows the actual cause. This can save a lot of time when troubleshooting issues such as:

HTTP 500 Internal Server Error
White screen or blank page
WordPress plugin or theme failures
PHP fatal errors or memory errors
Database connection issues
Incorrect file permissions
Broken redirects or rewrite rules
SSL and mixed-content problems after a migration

In hosting environments, the relevant logs may be separated into web server logs, PHP logs, application logs, and mail logs. For a broken website, the most useful ones are usually the web server error log and the PHP error log.

Where error logs are usually stored

The exact location depends on the hosting stack, but the following paths are common on Apache-based Linux servers and managed hosting platforms:

Apache error log: /var/log/apache2/error.log or /var/log/httpd/error_log
Virtual host error log: a domain-specific log under the hosting user directory or server logs folder
PHP error log: often defined in PHP settings or stored in a domain-specific file
Nginx error log: /var/log/nginx/error.log if Nginx is used as a reverse proxy or web server
Plesk logs: domain logs accessible from the control panel

On shared and managed hosting, you may not have direct server access. In that case, the hosting control panel usually provides log access through a website or domain management section.

How to find error logs in Plesk

If your hosting account uses Plesk, the log viewer is usually the easiest way to inspect website errors.

View logs for a specific domain

Log in to Plesk.
Open Websites & Domains.
Select the broken domain.
Click Logs or Log Browser.
Filter by Error or review entries around the time the issue started.

Plesk often shows Apache, Nginx, PHP, and sometimes application-related messages in the same place. If your site is on a modern stack with Nginx in front of Apache, both layers may generate useful messages.

Enable logging if it is not visible

If no logs appear, check whether logging is enabled for the domain. In some cases, the site is set to suppress detailed output, or the log rotation policy has moved older entries into archived files. Your hosting provider may also restrict direct log access depending on the plan.

How to find logs from the control panel without SSH

If you do not have shell access, you can still troubleshoot from the hosting panel. Look for sections named:

Logs
Error Logs
Raw Access Logs
Statistics
Domains or Websites
Advanced or Developer Tools

For application errors, some CMS platforms also write their own logs. For example, WordPress may generate debug output if WP_DEBUG is enabled, while Laravel, Magento, and similar applications may store errors in a dedicated storage/logs folder.

How to find error logs with SSH access

If your plan includes SSH access, you can inspect logs directly. This is useful when a site fails only under certain conditions or when you need to follow errors in real time.

Check common log files

Typical commands include:

tail -f /var/log/apache2/error.log
tail -f /var/log/httpd/error_log
tail -f /var/log/nginx/error.log
tail -f /var/log/php*-fpm.log

You can also search within a log file for recent errors:

grep -i error /path/to/logfile
grep -i fatal /path/to/logfile
grep -i denied /path/to/logfile

If you are not sure which log is relevant, reproduce the broken page in a browser and then check the latest timestamps in the logs. Match the time of the request with the error entry.

What to look for in the logs

Not every log line means the site is broken. Focus on messages that include errors, warnings, or denied access entries. The most useful patterns include:

PHP fatal errors

These usually indicate that a plugin, theme, custom script, or PHP extension failed. Common examples:

PHP Fatal error: Uncaught Error
Allowed memory size exhausted
Call to undefined function
Class not found
Maximum execution time exceeded

Fatal PHP errors often cause a white screen, a 500 error, or a partial page failure.

Web server errors

Apache or Nginx errors may show:

Permission denied
File does not exist
rewrite or redirect loop
invalid command
client denied by server configuration

These messages are useful when a page fails after a migration, a .htaccess edit, or a change in rewrite rules.

Database errors

If the website depends on MySQL or MariaDB, log entries may mention database connectivity issues such as:

Error establishing a database connection
Connection refused
Access denied for user
Too many connections

These problems can appear after password changes, database user changes, resource limits, or service outages.

File and permission errors

Permission-related failures often follow file uploads, restores, or deployments. Look for:

Permission denied
Operation not permitted
Failed to open stream
Unable to write to file

Wrong ownership or file mode settings can prevent PHP from reading config files or writing cache files.

How to enable application debugging safely

Sometimes the hosting error log does not show enough detail, especially with CMS applications. In that case, you can enable application-level debugging temporarily. Do this carefully, especially on live sites, because detailed error output may expose sensitive information.

WordPress debug mode

For WordPress, the most useful configuration is usually in wp-config.php. Enable logging rather than showing errors directly to visitors. This helps record the issue without exposing stack traces on the front end.

Check for log output in the WordPress debug file or in the hosting error log, depending on your setup.

Laravel and similar frameworks

Framework-based sites often store logs in an application folder such as storage/logs. Review the latest file and check the timestamp of the failure. These logs are often more detailed than server logs and may identify the exact controller, route, or dependency causing the break.

Magento, Drupal, Joomla, and custom apps

Many CMS platforms and custom applications keep their own logs in the project directory or in a configured log path. If the site is broken after an update, installation, or import, the application log can point to a missing module, incompatible version, or database schema issue.

Using logs to troubleshoot common broken website scenarios

Blank page or white screen

A blank page often means PHP crashed before output could be sent. Check for fatal errors, memory exhaustion, or missing class files. If the site uses a CMS, disable recent extensions or themes and retest after checking the logs.

500 Internal Server Error

This is one of the most common cases where error logs help. Look for:

Broken .htaccess rules
PHP fatal errors
File permission problems
Server-side restrictions on execution

If the error started after a deployment, compare the time of the deployment with the log timestamp to narrow down the cause.

404 errors on pages that should exist

If important pages suddenly return 404, check rewrite rules, permalink settings, and routing configuration. In Apache environments, the logs may show rewrite failures or blocked access to files. For CMS platforms, refreshing permalinks or route caches may solve the issue.

Redirect loops or HTTPS issues

Log files can show repeated requests between HTTP and HTTPS or between www and non-www versions. This usually means a redirect rule, proxy setting, or application base URL is misconfigured. If the issue began after adding SSL, review the site URL settings and any force-HTTPS rules.

Email-related application failures

Because this category includes DNS and email-related issues, note that a broken website can sometimes be caused by failing outbound email or mail queue problems in a web application. For example, password reset forms, contact forms, or order confirmations may fail if SMTP settings, DNS records, or mail authentication are incorrect. In these cases, look for mail transport or authentication messages in the application log and test the mail configuration separately.

How to match a log entry to the broken request

To avoid guessing, use the timestamp and request path. A good troubleshooting method is:

Open the broken page in a browser.
Note the exact time of the failure.
Check the logs for entries at that time.
Look for the requested URL, file path, or PHP script name.
Identify the first error in the chain, not just the last one.

The first error is often the true cause. Later messages may simply be side effects.

What to do after you find the error

Once you identify the message, take the appropriate corrective action:

PHP error: update or roll back the plugin, theme, or custom code
Memory error: increase PHP memory limit if allowed, or optimize the script
Permission issue: fix ownership and file modes
Rewrite error: restore a valid .htaccess or routing configuration
Database issue: verify credentials, service status, and user privileges
Missing file: restore the file from backup or redeploy the application

If the error is not obvious, capture the exact log line and share it with support. Include the time, domain name, and the page that fails. That gives the hosting team enough context to investigate server-side causes faster.

Best practices for working with error logs

Check the log immediately after reproducing the issue.
Use the time of failure to narrow down the relevant entries.
Keep a copy of the affected log lines before making changes.
Disable debug output after troubleshooting to protect sensitive data.
Review recent changes first: updates, imports, plugin installs, DNS edits, and SSL changes.
Do not rely on the browser error alone; always verify the server log.

For managed hosting accounts, it is also useful to know whether logs are rotated daily or weekly. If you wait too long, the exact error may move to an archived file and become harder to access.

FAQ

Where can I find error logs if I use Plesk?

Open the domain in Websites & Domains, then select Logs or Log Browser. There you can review Apache, Nginx, and PHP entries for that site.

Why does my website show a 500 error but no message is visible?

Many hosting environments hide detailed errors from visitors for security reasons. The real cause is usually in the server error log or PHP log.

Can I find logs without SSH access?

Yes. Most hosting control panels offer a logs section for each domain. You may also be able to use a file manager or application-specific debug logs.

What is the difference between access logs and error logs?

Access logs record each request to the website. Error logs record failures, warnings, and server-side issues. For a broken site, the error log is usually the most important.

How long are logs kept?

This depends on the hosting provider and log rotation settings. Some logs are kept for a few days, while others remain available longer through archived files or the control panel.

Should I enable debug mode on a live website?

Only temporarily and only if needed. Detailed debug output can reveal file paths, credentials, or stack traces. Prefer logging to a file rather than displaying errors to visitors.

What if the log does not show any error?

If the log is empty, the problem may be outside the web server layer, such as DNS pointing, SSL configuration, caching, or an upstream service issue. In that case, test the site from a different network, verify DNS records, and check whether the issue affects only one domain or the entire account.

Conclusion

Finding the error logs is one of the fastest ways to diagnose a broken website on a hosting platform. Whether you use Plesk, a custom control panel, or SSH access, the logs usually reveal whether the issue is caused by PHP, Apache, Nginx, a database connection, permissions, or application code.

Start with the domain-level logs, match the timestamp to the broken request, and focus on the first meaningful error. In most cases, that single entry will point you to the next step and shorten the time needed to restore the site.

How to Find Error Logs for a Broken Website