If you are troubleshooting a Java website, WAR deployment, JSP page or servlet application in Plesk, the first place to check is the log area for the domain and the Tomcat service logs tied to your hosting account. In a managed hosting environment, these logs are often the fastest way to identify startup failures, deployment errors, classpath issues, Java exceptions and connector problems.
In ITA’s Plesk-based Java hosting setup, Tomcat is managed through the My App Server extension. That means the most useful logs are usually found in two places: the domain logs inside Plesk and the application server logs related to your private JVM or Tomcat instance. Knowing where each log lives will save time when you need to diagnose a failed deploy or understand why an app is not responding as expected.
Where Tomcat-related logs are usually stored in Plesk
Plesk keeps web server logs at the subscription or domain level, while Tomcat and Java runtime logs are typically stored within the application server environment created for your site. The exact path can vary depending on how the service was installed, which Java version you selected and whether the app server was created with a default setup or custom configuration.
In practice, you should look in these locations first:
- Domain logs for Apache and Nginx access/error output.
- My App Server / Tomcat logs for Java runtime messages, startup output and deployment errors.
- Application-specific logs if your application writes its own log files.
If you are using a shared hosting account with private JVM support, Tomcat logs are often kept inside the service directory created for that application server rather than in the standard web root. The useful log files are usually named to reflect their purpose, such as catalina, localhost, manager, host-manager or a custom application log depending on the installed setup.
How to find Tomcat logs in the Plesk interface
The quickest way to begin is from the Plesk panel for your subscription or domain. The steps below are the usual path for locating log data for a Tomcat-based site.
Step 1: Open the domain in Plesk
Log in to Plesk and choose the domain or subdomain where your Java application is hosted. If the site is connected to My App Server, the domain may show a Java or application server section rather than a standard PHP-only hosting layout.
Step 2: Check the Logs page
In the domain tools, open Logs. This area normally shows Apache and Nginx access and error logs. These logs are useful when:
- the browser shows a 500 or 502 error;
- Tomcat starts but the site does not load correctly;
- the reverse proxy or web server cannot reach the Java application;
- a WAR deployment is mapped incorrectly to the domain.
Even when the actual exception is inside Tomcat, the front-end web server logs may show a clue such as a timeout, a proxy failure or a bad upstream response.
Step 3: Open the My App Server or Java service controls
If your hosting plan includes ITA’s Java hosting extension, locate the My App Server section in Plesk. From there you can usually view the service status, choose the Java version, control the Tomcat instance and access service-related details. Depending on the configuration, there may be direct links to logs or useful service paths.
This is especially important if the Tomcat instance is running as a private JVM under your hosting account. In that case, the service logs are often more relevant than the general website logs.
Step 4: Use File Manager when needed
If Plesk does not expose the exact Tomcat log file in the interface, open File Manager and look in the application server directory created by My App Server. Common folders include locations for:
- service logs;
- Tomcat startup output;
- temporary files;
- deployed application content;
- custom application logs.
For managed hosting, you may not need to edit these files directly, but File Manager can help you confirm whether a log file is being created and whether it is actively changing.
Which Tomcat log files matter most
Not every log file is equally useful. When you are trying to solve a problem quickly, these are the ones to check first.
catalina.out or catalina log files
This is usually the most important Tomcat log for startup and runtime problems. It may show:
- Java exceptions during startup;
- missing classes or JAR files;
- configuration errors in server.xml or context settings;
- port binding issues;
- application deployment failures.
If a WAR file deploys but the app does not respond, catalina-related output is often the first place to look.
localhost log files
These logs often contain application context messages and servlet container activity for the local host mapping. They are useful when the server starts correctly but one virtual host or one application path fails.
Access and error logs from Apache or Nginx
In a Plesk-based environment, the web server in front of Tomcat may still be handling requests. Its logs can show:
- request routing problems;
- proxy errors to the Java backend;
- SSL or redirect issues;
- client-side request patterns;
- response codes such as 404, 403, 500 or 502.
These logs do not replace Tomcat logs, but they often explain why traffic is not reaching the application cleanly.
Application-specific logs
Some Java applications write their own logs using frameworks such as Logback, Log4j or java.util.logging. If your app has a custom logging path, check the application configuration files and the directory where the application writes its output. In many cases, the app log gives the most precise error message, while the Tomcat log shows the container-level failure around it.
Typical log locations in a My App Server setup
The exact directory structure depends on the installation, but the following examples describe the kind of place where you may find Tomcat-related logs in a hosted Plesk setup:
- the service home directory for the Java app server;
- a logs folder inside the Tomcat installation tree;
- a temp or work directory for startup and runtime data;
- the domain’s own log directory for Apache or Nginx logs;
- a custom folder defined by the application itself.
If you have installed a Tomcat version manually or uploaded a custom app server configuration, the log path may reflect that custom layout. The main rule is simple: front-end logs are in the domain area, Java container logs are inside the My App Server environment.
What to look for in Tomcat logs
When reading Tomcat-related logs, focus on the first error that appears before the stack trace grows large. In Java hosting, a later exception is often caused by an earlier root problem.
Common patterns include:
- ClassNotFoundException or NoClassDefFoundError — missing dependency or wrong JAR placement;
- BindException — port already in use or service conflict;
- SEVERE startup messages — container-level failure;
- OutOfMemoryError — memory limit too low for the application;
- Deployment exception — WAR file issue, invalid context, broken web.xml or unpack failure;
- Permission denied — file access problem in the hosting account;
- SSL/proxy warnings — routing or certificate mismatch at the web server layer.
If the log is long, search for the words SEVERE, ERROR, Exception, Fail, Stopped or Unable. These markers often identify the exact moment the server or application failed.
How logs help with Java hosting and WAR deployments
In a Tomcat hosting environment, logs are essential during deployment. A WAR file can upload successfully and still fail at runtime because of a missing library, invalid environment variable or incompatible Java version.
Use logs to verify these common situations:
- the WAR file was deployed but the context path is wrong;
- the selected Java version does not match the application requirement;
- the app expects a database connection that is not configured;
- the application tries to access a file path outside its permissions;
- startup is delayed by an expensive initialization step;
- the reverse proxy cannot connect to the Tomcat backend.
Because ITA’s My App Server approach gives you control over a private JVM and selected Tomcat version, logs become the best way to confirm that the deployed runtime is behaving as expected. This is especially useful for smaller Java and JSP applications where you want direct visibility without managing a full enterprise stack.
Checking logs when the application does not start
If Tomcat will not start, begin with the service control area in Plesk and then inspect the latest log entries. A non-starting service often leaves a clear trail.
Use this checklist:
- Confirm the service is enabled and started in My App Server.
- Check whether the selected Java version is available and compatible.
- Review the latest catalina output for startup exceptions.
- Check whether the port is already occupied by another service.
- Verify that the application files are present and readable.
- Inspect the domain logs for proxy or HTTP-level failures.
If the service starts and then stops immediately, the log usually contains a direct reason such as a configuration parse error or application initialization failure.
Checking logs when the site returns 500 or 502 errors
HTTP 500 and 502 responses are common in Tomcat-based hosting. They do not always mean the same thing, so the logs help narrow it down.
- 500 Internal Server Error often points to an application-side exception inside Tomcat.
- 502 Bad Gateway often means the front-end web server could not reach the Java backend or received an invalid response.
For 500 errors, check the Tomcat and application logs first. For 502 errors, check both the domain logs and the Tomcat service status. In many cases, the issue is not the website code itself but a mismatch between the reverse proxy and the Java process.
Best practice for reviewing log files in Plesk
To avoid missing the real problem, use a simple method when reading logs:
- open the most recent entries first;
- look for the first error before the stack trace expands;
- match the timestamp with the time you reproduced the issue;
- compare Tomcat logs with the web server logs;
- note any change after a deploy, restart or Java version update.
When possible, reproduce the issue after opening the log viewer so you can see the exact moment the error occurs. This is especially helpful for intermittent startup errors or application-level exceptions triggered by a specific request.
Log access and service control in managed Java hosting
In a managed Plesk hosting environment, you usually control the app server from a central interface rather than by SSH-only administration. This makes it easier to start, stop or restart Tomcat, switch Java versions and inspect related logs from one place.
That approach is practical for:
- small and medium JSP applications;
- servlet-based websites;
- WAR deployments with a private JVM;
- Java apps that need straightforward control in Plesk;
- developers who want container visibility without managing a full standalone server stack.
If your application is custom-built, logs are also the best way to verify whether it behaves differently under one Java version versus another. For example, a class loading error may appear only after switching runtime versions, which makes the log history very valuable.
FAQ
Are Tomcat logs the same as Plesk domain logs?
No. Domain logs usually show web server traffic, requests and proxy behavior. Tomcat logs show the Java container activity, startup messages and application exceptions. Both can be useful, but they serve different troubleshooting needs.
Why can’t I see a Tomcat log file in the Plesk Logs screen?
The Logs screen often focuses on the web server layer. Tomcat logs may be stored in the My App Server directory or another service folder that is not shown by default. In that case, use File Manager or the service controls to locate the app server log path.
What is the most important log file for a failed Java deploy?
Usually the catalina-related log is the first file to read. It often contains the exact exception or startup problem that caused the deployment to fail.
Can I use logs to check whether my Java version is correct?
Yes. If the app is incompatible with the selected Java version, the Tomcat logs often show class loading errors, runtime exceptions or initialization failures shortly after startup.
Do I need SSH to review Tomcat logs?
Not always. In many Plesk setups, you can inspect the main web server logs from the panel and use File Manager or the application server section for Tomcat-related files. SSH can help in more advanced cases, but it is not always required.
What should I send to support if my Tomcat app is failing?
Provide the exact time of the issue, the domain name, a short description of the action you performed, and the relevant log snippet from both Plesk and the Tomcat service logs. The timestamp is especially important for fast diagnosis.
Summary of the fastest path to the right log
If your Java site is failing in Plesk, start with the domain Logs page, then move to the My App Server service logs, and finally check any application-specific log files. In a Tomcat hosting setup, that sequence usually reveals whether the problem is at the web server layer, the Java container layer or inside the application itself.
For ITA Java hosting customers using My App Server, this log-based approach is the most practical way to debug WAR deployments, JSP applications and private JVM services without needing a large enterprise setup. Once you know where the logs are, most Tomcat issues become much easier to trace and resolve.