Where to Find Logs and Errors in Plesk

When a website, mailbox, or application starts behaving unexpectedly, the fastest way to identify the cause is usually through logs. In Plesk, those logs are often the first place to check for web server errors, mail delivery issues, application failures, and backup problems. If you manage hosting in a Plesk control panel, knowing where to find logs and how to read them can save time during troubleshooting and help you resolve issues before they affect users.

This guide shows where to find the main log locations in Plesk, how to view them from the panel, and what to look for when diagnosing common hosting problems. It also explains the difference between website logs, mail logs, and backup logs so you can find the right information quickly.

Where logs are located in Plesk

Plesk provides access to several types of logs depending on what you are troubleshooting. The most useful ones are:

Website and web server logs for Apache, Nginx, and application errors.
Mail logs for email delivery, authentication, and spam-related problems.
Backup logs for failed backup runs, restore errors, and storage issues.
System and panel logs for Plesk itself, scheduled tasks, and service-level errors.

In most cases, you can access the relevant logs directly from the Plesk interface. For deeper investigation, especially on managed hosting platforms, you may also need to review log files via SSH or ask support to check server-side logs.

How to view website logs in Plesk

For website issues, Plesk usually provides access to access logs and error logs from the domain level. These logs are useful when a site returns a 500 error, shows a blank page, has redirect loops, or fails to load certain resources.

Open the domain logs

Log in to Plesk.
Go to Websites & Domains.
Select the domain you want to inspect.
Open Logs.

In the Logs section, you may see entries from Apache, Nginx, PHP, and other components depending on your hosting stack.

What you can find there

404 errors for missing pages or broken links.
500 Internal Server Error messages caused by script or configuration issues.
403 Forbidden errors related to permissions, security rules, or directory settings.
PHP fatal errors, warnings, and deprecated function notices.
SSL/TLS related issues if requests are failing over HTTPS.
Rewrite and redirect problems that cause loops or unexpected page changes.

If your hosting plan uses both Apache and Nginx, the log output may include entries from both web servers. This is normal and often helpful when determining whether the problem is happening at the proxy layer, the web server layer, or inside the application.

How to use the log viewer in Plesk

Plesk’s log viewer makes troubleshooting easier by showing recent events in a readable format. You can often filter or inspect entries by time, type, or severity depending on the panel configuration.

Useful things to check in website logs

Timestamp to match the error with a user report.
Status code such as 200, 301, 403, 404, or 500.
Requested URL to see which page or file caused the problem.
Client IP if you need to identify repeated requests or blocked access.
Error text for PHP, permission, or routing details.

When troubleshooting, try to compare a successful request with a failing one. For example, if the homepage works but the admin area does not, the log may show a missing file, incorrect rewrite rule, or PHP compatibility issue for that specific path.

Where to find mail logs in Plesk

Mail logs are essential when email does not arrive, messages are rejected, or authentication fails. In a Plesk hosting environment, mail-related logs help you trace SMTP, IMAP, and POP3 activity, as well as delivery and relay errors.

Check mail-related events

Depending on your access level and server configuration, you may find mail logs in the Plesk interface or through the server’s mail service logs. If you manage mailboxes in Plesk, the following areas are worth checking:

Domains > Mail for mailbox settings and service status.
Mail settings for routing, antivirus, and spam filter configuration.
Logs for message delivery attempts and mail server responses.

Common mail issues visible in logs

Authentication failures due to wrong passwords or unsupported authentication methods.
Delivery errors when outgoing messages are rejected by the recipient server.
Mailbox full messages if the account has reached its storage limit.
Spam or policy blocks if messages are flagged by filtering systems.
SMTP relay denied errors when a client tries to send mail without proper authorization.

If users report that email is sent but not received, look for delivery status messages and recipient-side rejections. If outgoing mail is failing from an application such as a contact form or CMS, check whether the site is configured to use the correct SMTP settings and whether the logs show connection or authentication errors.

Where to find backup logs in Plesk

Backup logs are important when scheduled backups fail, restores do not complete, or a backup job takes much longer than expected. In Plesk, backups are often managed through the backup manager, and logs can help you determine whether the issue is related to disk space, permissions, remote storage, timeout limits, or archive corruption.

Open the backup manager

Log in to Plesk.
Go to Tools & Settings or the subscription’s Backup Manager, depending on your role.
Review the list of backup tasks and their status.
Open the details or log output for the failed run.

If the backup was triggered by a scheduled task, the task history may show the start time, end time, and error message. This is often enough to identify the cause without deeper server access.

Typical backup log messages

Not enough disk space on local storage or the backup destination.
Permission denied when Plesk cannot read or write a file.
Connection failed to remote storage such as FTP, SFTP, or cloud destination.
Archive creation errors caused by locked files or filesystem issues.
Timeout exceeded for large sites, databases, or long-running tasks.

For large hosting accounts, backup logs are especially useful because failures may affect only one part of the account, such as a database, mailbox, or a specific directory. Reviewing the exact message helps you decide whether you need to free space, exclude temporary files, adjust a timeout, or contact hosting support.

Where to find system and panel logs

Sometimes the issue is not with a website or mailbox, but with Plesk itself. If the panel is slow, a task fails unexpectedly, or a service does not respond as expected, system logs can provide clues.

What system logs may show

Panel login issues and authentication problems.
Scheduled task errors for cron jobs or automation scripts.
Service restart failures for web, mail, or database services.
Extension errors if a Plesk extension is causing a conflict.
Permission and configuration errors affecting control panel operations.

If you do not see enough detail in the Plesk interface, support can often check deeper logs on the server. This is especially useful in a managed hosting environment where the platform provider has access to system-level diagnostics.

Useful log files and paths on the server

Depending on the operating system, web server, and mail stack, log paths may differ. The exact location can also vary between hosting providers. Still, the following locations are commonly used on Linux-based Plesk servers:

Web server logs: often under /var/www/vhosts/system/<domain>/logs/
Plesk panel logs: often under /var/log/plesk/panel.log
Mail service logs: commonly under /var/log/maillog or a related mail service log file
Backup-related logs: available in the backup manager or system task logs

If you are not sure where a specific log is stored, use the Plesk interface first. It is usually the fastest and safest way to review recent errors without needing shell access.

How to read common log entries

Log files can look technical at first, but most entries follow a similar pattern. A typical line may include a timestamp, service name, severity level, client IP, request path, status code, or error description.

Example patterns to recognize

404 Not Found means the requested file or page does not exist.
403 Forbidden means access is blocked by permissions or rules.
500 Internal Server Error usually points to an application, PHP, or configuration issue.
502 Bad Gateway often indicates a problem between Nginx and the backend service.
503 Service Unavailable may mean the site or service is temporarily overloaded or unavailable.

For mail logs, look for terms such as auth, relay, deferred, bounced, rejected, or quota exceeded. For backups, watch for failed, timeout, disk full, and permission denied.

Troubleshooting workflow when a problem occurs

If you are not sure where to start, use a simple workflow to narrow down the issue quickly.

Identify the symptom — website error, email issue, backup failure, or panel problem.
Match the time — note when the issue started or when a user reported it.
Open the relevant log — domain logs, mail logs, backup logs, or panel logs.
Check the exact error message — focus on the first meaningful failure, not only repeated follow-up errors.
Compare with recent changes — updates, DNS changes, new plugins, SSL renewals, or mailbox configuration changes.
Test again after adjustments — repeat the action and confirm the error no longer appears.

This workflow is especially effective in a managed hosting setup where multiple services can influence each other. For example, a website error may actually be caused by an expired SSL certificate, while an email issue could be tied to a firewall rule or authentication problem.

When to contact hosting support

Some log entries can be interpreted directly by site administrators, but others require server access or deeper knowledge of the hosting stack. Contact support if you see any of the following:

Repeated service crashes or restart failures.
Log entries that reference system-level permissions you cannot change.
Backup failures caused by storage or remote destination problems.
Mail delivery issues that continue after checking account settings.
PHP, Apache, or Nginx errors that are not resolved by application-level changes.

When contacting support, provide the timestamp, domain name, mailbox name, and the exact error message from the log. This helps the support team investigate faster and reduces back-and-forth.

Best practices for working with logs in Plesk

Logs are most useful when you use them consistently. A few simple habits can make troubleshooting much easier:

Check logs immediately after an error occurs, while the event is still recent.
Record the exact time and message before making changes.
Focus on the first error in a chain, not only on repeated follow-up messages.
Review both web server and application logs if the issue is website-related.
Review both client-side settings and server-side logs for email issues.
Keep backups and logs separate in your troubleshooting process so you check the correct area first.

For hosted environments serving European customers, reliable log access is especially important because it helps administrators maintain service quality, respond quickly to incidents, and keep websites and mailboxes running smoothly.

FAQ

Can I see all logs directly in Plesk?

You can usually see the most relevant logs for a domain, mailbox, or backup task directly in Plesk. Some deeper system logs may require server access or support intervention, depending on the hosting setup.

Why do I see both Apache and Nginx entries?

Many Plesk installations use Nginx as a reverse proxy in front of Apache. In that case, both services may write log entries, which is normal and useful for troubleshooting.

What log should I check for a 500 error?

Start with the domain’s error log and PHP-related messages. If needed, also review the application log, web server logs, and recent configuration changes.

Where should I look if emails are not being delivered?

Check the mail logs for authentication failures, relay issues, rejections, and quota problems. Also verify the mailbox settings and SMTP configuration in Plesk.

How can I tell if a backup failed because of storage space?

Backup logs usually mention disk space, quota, or destination errors clearly. If the message is not obvious, compare the backup size with available local or remote storage.

Do I need SSH access to view logs in Plesk?

Not always. Plesk often provides log access through the web interface. SSH is only needed for deeper investigation or for logs not exposed in the panel.

Conclusion

In Plesk, logs are one of the most valuable tools for diagnosing hosting issues. Whether you are dealing with website errors, mail delivery problems, or failed backups, the right log file can quickly show what went wrong and where to look next. Start with the domain logs for web issues, mail logs for email problems, and backup logs for scheduled task failures. If the issue appears to be panel-wide or system-related, review Plesk and service logs or contact hosting support with the exact error details.

By using logs as part of your regular troubleshooting process, you can resolve problems faster, reduce downtime, and keep your hosting environment stable and easier to manage.