If your Java application runs through Tomcat in Plesk, the fastest way to troubleshoot errors is to check the application and service logs in the right place. In a managed hosting setup, log locations can vary slightly depending on whether you use a built-in Tomcat package, a custom Tomcat instance, or a Plesk extension such as My App Server. The good news is that Plesk usually gives you enough visibility to find deployment errors, startup issues, servlet exceptions, and access problems without leaving the control panel.
For Java hosting, Tomcat hosting, JSP hosting, and servlet hosting, logs are often the first step when a WAR file will not deploy, a page returns a 500 error, or the application starts but does not respond correctly. This guide explains where to find Tomcat-related logs in Plesk, what each log type usually contains, and how to use them for faster diagnosis.
Where Tomcat-related logs are usually stored in Plesk
In a Plesk environment, Tomcat logs may be available in one or more of the following places:
- Domain log files inside the subscription or domain log area.
- Tomcat service logs generated by the Java application server itself.
- System or component logs if the Tomcat service is managed at server level.
- My App Server logs if your hosting plan uses ITA’s Java hosting extension for private JVM or Tomcat management.
The exact path depends on how the Tomcat service was installed and integrated with Plesk. In many hosting setups, the control panel separates standard web server logs from Java application logs, so it is important to know which layer is actually handling the request.
Check the Plesk domain logs first
When a Tomcat application fails to load, begin with the domain logs in Plesk. These logs often show whether the request reached Apache, whether a reverse proxy forwarded it, and whether the response returned a server error.
What you may find there
- HTTP 500, 502, 503, or 504 errors
- Request routing issues
- Missing files or invalid paths
- Proxy or connector problems between Apache and Tomcat
- Repeated access attempts from browsers, bots, or monitoring tools
In Plesk, open the domain or subscription, then go to the log section for the site. Depending on the setup, you may see separate access and error logs. These can help confirm whether the issue is only in Tomcat or begins earlier at the web server layer.
If the browser shows a generic error page, the domain error log is often the quickest way to see whether Tomcat responded at all.
Find Tomcat service logs in the Java hosting area
If you are using a private Tomcat instance, the most useful logs are usually inside the Java hosting or application server area rather than the standard website log viewer. With ITA’s My App Server extension, Tomcat is managed as part of the hosting account, which makes it easier to start, stop, and inspect the service from Plesk.
Look for sections related to:
- My App Server
- Java hosting
- Tomcat service control
- Application server logs
- Startup or deployment output
These logs are especially useful when:
- a WAR file deploys with an error
- Tomcat fails to start after a configuration change
- the application crashes during startup
- the wrong Java version is selected
- ports or context paths are misconfigured
On managed hosting platforms, the logs may be exposed through the control panel for convenience, even if the physical files are stored in the service directory on the server.
Common Tomcat log file names to look for
Tomcat log names vary by version and configuration, but several names appear frequently across Java hosting environments. If you have shell or file access, these are the typical files to check:
- catalina.out - general Tomcat output and startup messages
- catalina.log - core Tomcat runtime messages
- localhost.log - application-specific errors for the default host
- manager logs - deployment and management activity, if enabled
- application logs - custom logs written by the Java app itself
For many JSP and servlet applications, the most useful information appears in the startup output and the application stack trace. If your app uses a logging framework such as Log4j, SLF4J, or java.util.logging, the actual business logs may be written elsewhere and not only in the default Tomcat files.
How to interpret the most common messages
- ClassNotFoundException - a required library or class is missing
- SEVERE - a high-priority error that often needs immediate attention
- BindException - Tomcat could not bind to a port, often because it is already in use
- OutOfMemoryError - the JVM needs more memory or the app has a leak
- Failed to deploy - WAR deployment or file permissions may be incorrect
How to view logs in Plesk
The steps below may differ slightly depending on the hosting template and the Java extension in use, but the overall approach is similar.
Step 1: Open the domain or subscription
Log in to Plesk and select the domain where your Tomcat application is hosted. If your hosting account uses a separate Java app server area, open that service section as well.
Step 2: Go to the log section
Open the logs for the domain first. This usually shows the web server access and error logs. If you are using My App Server, check the Java service page for additional log output related to the Tomcat instance.
Step 3: Filter by time and error level
Look for entries at the exact time the issue occurred. Focus on lines marked as error, warning, fatal, or severe. For startup issues, compare the current log with the last successful restart.
Step 4: Correlate the request with the application log
If the domain log shows an HTTP 500 error, search the Tomcat log for the same timestamp. This often reveals the real cause, such as an exception inside a servlet, a missing configuration value, or a failed database connection.
Step 5: Save the relevant lines
When contacting support, copy the exact error lines, including timestamps and the surrounding context. This makes diagnosis much faster than sending only a screenshot.
Where to look if Plesk does not show enough detail
Sometimes the standard Plesk log view is not enough, especially when Tomcat is running as a private JVM or custom service. In that case, the logs may be stored in the service directory or application folder rather than in the visible domain log area.
Typical fallback checks include:
- the Tomcat installation directory
- the application’s
logsfolder - the Java service data directory
- custom log paths defined in
conf/logging.propertiesor the application’s logging configuration
If you are using ITA’s My App Server, the extension is designed to make this easier by keeping Java service management within Plesk. That is useful for shared hosting accounts that need a separate Tomcat or private JVM without full server administration.
Tomcat logs versus Apache logs in Plesk
It is common to confuse Apache errors with Tomcat errors because both may appear when a Java site stops working. A clean way to separate them is to check which layer failed first.
Apache logs usually show
- connection issues
- proxy forwarding problems
- missing virtual host configuration
- SSL or domain routing errors
- public-facing 4xx and 5xx responses
Tomcat logs usually show
- Java exceptions
- deployment failures
- JSP compilation errors
- servlet initialization issues
- JVM startup and shutdown messages
If Apache can reach Tomcat but the app still fails, the Tomcat logs are usually the source of truth. If the request never reaches Tomcat, start with the Apache or proxy logs.
Logs for WAR deployment problems
WAR deployment problems are among the most common reasons to inspect Tomcat logs in Plesk. A package may upload correctly but still fail to expand, initialize, or map to the expected context path.
Look for entries related to:
- exploded deployment errors
- invalid archive structure
- permission issues on the application directory
- missing libraries in
WEB-INF/lib - incorrect servlet mappings
If your hosting plan uses a built-in Java version selection tool, confirm that the app is running under the Java runtime it expects. Some applications behave differently across Java 8, Java 11, Java 17, and later versions.
Logs for startup and shutdown issues
When Tomcat will not start or stops unexpectedly, startup logs are the most valuable source of information. Check the last lines before shutdown or failure, because they usually point to the exact module or configuration item that caused the problem.
Common causes include:
- port conflicts
- invalid JVM arguments
- memory settings that are too aggressive for the hosting limits
- broken deployment descriptors
- unsupported library versions
In shared hosting, the JVM settings and service limits are usually controlled to keep the environment stable. If a configuration worked locally but fails in Plesk, compare the memory, port, and Java version settings first.
How logs help with servlet and JSP debugging
For servlet hosting and JSP hosting, log output is often the fastest way to identify compile-time and runtime issues. A page may look fine in the browser, but a JSP compilation failure or missing bean class can still break the request on the server.
Useful patterns to search for include:
- Jasper compilation errors
- tag library loading errors
- missing servlet annotations
- NullPointerException in controller code
- database connection failures during request handling
Because JSP files are compiled by the server, errors may only appear in the log and not directly in the browser. That is why Tomcat-related logs are essential during development and support troubleshooting.
Best practice for checking logs on managed hosting
On managed hosting platforms, the goal is to collect enough detail to diagnose the issue without changing the server unnecessarily. A practical workflow is:
- check the browser error message
- check the Plesk domain log for the same timestamp
- check the Tomcat or My App Server log for the root exception
- review recent deployment or configuration changes
- restart the Java service only after you have captured the error
This approach helps avoid losing useful log lines after a restart. It also makes it easier to distinguish a temporary issue from a repeatable configuration problem.
When to contact support
Contact support if you can confirm that:
- the error repeats with the same timestamp pattern
- Tomcat fails before the application fully loads
- the logs show a permission, port, or service-control issue you cannot change from Plesk
- the application needs a specific Java version that is not available in the current setup
- the log points to a hosting-side limit or service restriction
When you open a support request, include the relevant log excerpts, the domain name, the approximate time of the failure, and the action that triggered it. For example, mention whether the issue happened after a WAR upload, a Java version switch, or a service restart.
FAQ
Can I find Tomcat logs directly in Plesk?
Yes, in many hosting setups you can find at least the domain logs in Plesk, and in Java hosting environments such as My App Server you may also have access to Tomcat-related service logs from the control panel.
Why do I see an HTTP 500 error but no clear message in the browser?
The browser often shows only a generic error page. The detailed cause is usually in the Tomcat log, such as a Java exception, missing class, or deployment failure.
What is the difference between access logs and error logs?
Access logs record requests made to the site. Error logs record server-side problems. For Tomcat troubleshooting, both can help, but the error log is usually more important.
Do I need shell access to read Tomcat logs?
Not always. In Plesk, some logs can be viewed through the control panel. However, if the Tomcat instance is custom or private, shell or file access may be needed to inspect all log files.
Why does my app work locally but fail in Plesk?
Common reasons include a different Java version, memory limits, missing libraries, a different context path, or permissions that are stricter in the hosting environment. The log usually shows the exact mismatch.
Can Tomcat logs show deployment problems with a WAR file?
Yes. WAR deployment issues are one of the most common reasons to inspect Tomcat logs. They often reveal archive problems, missing dependencies, or application initialization errors.
Summary
To find Tomcat-related logs in Plesk, start with the domain log area, then move to the Java hosting or My App Server service logs if your application runs on a private Tomcat instance. For Java hosting, Tomcat hosting, JSP hosting, and servlet hosting, the most useful details are often in startup output, deployment messages, and application exceptions. If the public site shows an error but the cause is not obvious, the Tomcat log usually contains the root problem.
Using Plesk for log review is especially practical in a managed hosting environment because it keeps service control, Java version management, and diagnostics in one place. When you know where to look, troubleshooting becomes much faster and more reliable.