If you are running Java applications in Plesk, the most useful log files are usually the web server logs, the application server logs, and any custom logs created by Tomcat or your own JVM process. For troubleshooting deployment issues, HTTP 404 and 500 errors, startup failures, servlet exceptions, or requests that never reach your application, checking the right log file is often the fastest way to identify the cause.
In a managed hosting environment with Plesk, log locations can vary slightly depending on how your domain is configured and whether your Java application runs through a built-in Tomcat instance, a custom app server, or a private JVM managed through a Plesk extension such as My App Server. The good news is that Plesk gives you a central place to review most of the relevant logs without needing full shell access in many cases.
Where Java-related logs are usually stored in Plesk
Java-related logs in Plesk are typically found in one of these places:
- Domain logs for Apache or nginx requests, including access and error logs.
- Tomcat logs for servlet, JSP, and application startup messages.
- Java application logs created by your app, framework, or custom configuration.
- System or service logs if your private JVM or custom app server writes output there.
If you are using a Java hosting setup with a separate Tomcat or JVM inside your hosting account, the most important logs are usually the Tomcat stdout and stderr logs, the application log file configured by your app, and the domain-level web server error log.
Common log types to check first
- Access log - shows incoming requests, response codes, client IPs, and URLs.
- Error log - records server-side errors, rewrite issues, permission problems, and proxy failures.
- Tomcat Catalina log - useful for startup, shutdown, and deployment messages.
- stdout/stderr logs - capture console output from the Java process.
- Application-specific logs - may include Spring, Hibernate, framework, or custom business logs.
How to open logs in Plesk
Plesk provides a simple interface for viewing recent logs for each domain. This is often the quickest way to confirm whether the problem is at the web server layer or inside the Java application itself.
- Log in to Plesk.
- Open Websites & Domains.
- Select the domain where the Java application is installed.
- Open Logs.
- Filter or inspect entries for errors, failed requests, and status codes such as 500, 502, 503, or 404.
The Logs screen is especially helpful when a site is served through Apache or nginx in front of Tomcat. If the request never reaches the application, the domain error log may show proxy, rewrite, or gateway issues. If the request reaches the app but fails inside Java, you will often see stack traces in the Tomcat or app logs instead.
What to look for in the domain logs
- Repeated 500 Internal Server Error responses.
- 502 Bad Gateway or 503 Service Unavailable messages.
- Missing resource paths such as JSP, WAR, static assets, or API endpoints.
- Permission-related errors for files, directories, or socket connections.
- Proxy or rewrite problems when Apache forwards traffic to Tomcat.
Finding Tomcat logs in a Java hosting setup
If your account uses Apache Tomcat through a Plesk extension such as My App Server, the Tomcat logs are usually the most valuable source of information for Java troubleshooting. These logs often show deployment details, class loading problems, initialization errors, and servlet exceptions.
Depending on the configuration, Tomcat log files may include names similar to the following:
- catalina.out
- catalina.<date>.log
- localhost.<date>.log
- manager.<date>.log
- host-manager.<date>.log
- stdout.log and stderr.log
If you use a managed hosting platform with Java support in Plesk, the exact path can depend on how the service was provisioned. In many setups, you can access the log location from the service controls or from the application server configuration screen.
Typical Tomcat log contents
- Deployment success or failure for WAR files.
- Missing libraries or dependency conflicts.
- Port binding issues when the JVM or Tomcat starts.
- Context path problems.
- JSP compilation errors.
- Java exceptions thrown during request processing.
Using My App Server in Plesk to locate Java logs
In an ITA-style Java hosting environment, My App Server is the Plesk extension used to install and manage a private JVM or Apache Tomcat instance under your hosting account. This is useful for Java hosting, Tomcat hosting, JSP hosting, and servlet hosting where you need direct control over the runtime without managing a full dedicated application server platform.
From a log perspective, My App Server can help you identify where the service stores its output, what Java version is active, and whether the service is running correctly. If the app server is managed from Plesk, check the service details and control options first. These often point you to the relevant process output or service-specific logs.
What to check in My App Server
- Service status: running, stopped, or failing to start.
- Selected Java version and runtime configuration.
- Tomcat or custom app server instance details.
- Paths for startup output and error output.
- Application deployment directory and context settings.
If your application starts and then fails immediately, the most useful entries are usually in the startup output. If the service runs but requests fail, check both the server logs and the application-level logs.
How to read the most useful log errors
When reviewing Java-related logs in Plesk, focus on the first error in the chain rather than the final generic failure message. A single root cause often triggers multiple follow-up errors.
Common patterns and what they usually mean
- ClassNotFoundException - a required class or library is missing.
- NoClassDefFoundError - dependency not available at runtime or incompatible version.
- Port already in use - another service is using the same port.
- Permission denied - the Java process cannot read or write a file or directory.
- NullPointerException - application logic error, often in startup code or request handling.
- JSP compilation error - syntax problem or missing import in a JSP file.
- OutOfMemoryError - JVM memory limit may be too low for the workload.
If you see a stack trace, start from the topmost application error and then trace backward to the first configuration or dependency problem mentioned in the log.
Where to check logs on the server file system
In some Plesk environments, you may need to access logs through the file manager or via SFTP. The exact directories vary by setup, but Java hosting accounts often keep application files and logs inside the subscription directory or service-specific folders.
Typical places to look include:
- The domain’s logs folder.
- The Tomcat installation or instance directory.
- Your application’s own logs directory.
- Custom paths defined in logback.xml, log4j.properties, or application configuration.
- Service output files configured by the Java runtime or startup script.
If you do not see logs in Plesk’s Logs screen, the file may still exist in the application directory or inside the Tomcat instance folder. For custom app servers, the log path may be part of the service configuration rather than the domain configuration.
Logging differences between Apache, nginx, and Tomcat
In a typical hosting control panel setup, web traffic may pass through nginx, Apache, and then Tomcat. Each layer can generate its own logs, and each layer is useful for a different kind of problem.
Apache or nginx logs
These help with:
- HTTP response errors.
- Redirect and rewrite issues.
- Static file access problems.
- Proxy forwarding problems to Tomcat.
Tomcat logs
These help with:
- Servlet startup and deployment.
- Context initialization.
- Java exceptions during request handling.
- WAR file deployment and reload issues.
Application logs
These help with:
- Business logic errors.
- Framework-level messages.
- Database connection problems.
- Custom debug information.
For example, if Apache shows a 502 error, the issue may be that Tomcat is down or not reachable. If Apache and Tomcat both look healthy but your application still fails, the problem is more likely in the app log or JVM configuration.
Best practice for troubleshooting Java issues in Plesk
When a Java application is not working properly, use a simple log review sequence to save time.
- Check the domain log for the HTTP status code and request path.
- Check Tomcat output for startup errors or stack traces.
- Check the application log for business-level failures.
- Compare timestamps so you can match the request with the error.
- Look at the first root cause instead of only the final exception.
This approach is especially useful when you are deploying WAR files, updating JSP pages, or switching Java versions in a private JVM. A problem introduced during deployment is usually visible in the logs within seconds.
How to handle log rotation and older entries
On busy hosting accounts, logs can grow quickly. Plesk and the underlying system may rotate logs automatically, which means older entries are moved to dated files or compressed archives. If you cannot find an error from a previous day, it may already be in a rotated log file.
When investigating older incidents, look for files with date suffixes or compressed extensions. If your app server is managed by My App Server, check whether the service keeps its own rotated output files in a separate directory.
Tips for working with rotated logs
- Match the exact timestamp of the failure.
- Check both current and rotated files.
- Search for the application name, context path, or exception type.
- Keep a copy of important logs before making configuration changes.
When logs are not enough
Sometimes the logs show only a symptom, not the cause. If the application starts but behaves incorrectly, you may need to check the following as well:
- Java version compatibility.
- Tomcat version compatibility.
- WAR deployment structure.
- File and folder permissions.
- Environment variables or JVM options.
- Database connection strings and credentials.
For example, a JSP application may load fine but fail only when a specific page is requested because a dependency is missing from the runtime classpath. In that case, the server logs point to the page or class involved, but the real fix may be in the build or deployment package.
FAQ
Where do I find Java logs in Plesk?
Start with the domain’s Logs section in Plesk. Then check the Tomcat output files and any application-specific logs if the issue appears to be inside the Java application rather than the web server.
Which log should I check first for a 500 error?
Check the domain error log first, then the Tomcat logs. If the web server only shows a generic 500 response, the detailed error is often in the Java application or Tomcat output.
What if my Java app uses a private JVM?
If you are using a private JVM managed through a Plesk extension such as My App Server, check the service status and the runtime output logs for that specific instance. The application may write logs outside the standard domain log area.
Can I view Tomcat logs without SSH?
In many Plesk setups, yes. You can often view recent logs in the control panel. However, older files or custom log paths may require file manager or SFTP access.
Why do I see 502 or 503 errors instead of Java stack traces?
These usually indicate a problem between the web server and Tomcat, such as the service being stopped, a bad proxy route, or a port mismatch. The detailed cause is usually in the web server or app server logs, not on the browser page.
Do Java logs include JSP compilation errors?
Yes. JSP compilation errors are often written to Tomcat logs and can also appear in application output. These errors usually point to syntax mistakes, missing imports, or unavailable classes.
Summary
To find Java-related logs in Plesk, start with the domain logs in Websites & Domains > Logs, then move to Tomcat output and any custom application logs created by your Java app. In a Plesk-based Java hosting setup with My App Server, the most useful files are usually the web server error log, the Tomcat startup and console logs, and the application’s own log files. Checking them in the right order makes it much easier to diagnose deployment errors, startup failures, servlet exceptions, and request-processing issues.
For Java, Tomcat, JSP, and servlet hosting, the key is to match the log layer to the problem layer: web server logs for request routing issues, Tomcat logs for server and deployment problems, and application logs for code-level errors. This gives you a practical way to troubleshoot quickly inside Plesk without unnecessary guesswork.