In Plesk, Java-related logs are usually the fastest way to understand why a Tomcat application, JSP site, or private JVM service is not starting as expected. If you use a hosting platform with a Java extension such as My App Server, the relevant log files may be spread across the application server, the domain, and sometimes the Plesk event log. Knowing where to look saves time when you are troubleshooting startup errors, deployment problems, memory issues, or application exceptions.
The exact log location depends on how your Java hosting service is configured, whether you are using a built-in Apache Tomcat setup, a custom app server, or a manually uploaded Java runtime. In most cases, you should check both the application server logs and the domain logs, because one often explains the other. For example, Tomcat may record a startup exception, while Apache or the domain log shows that a request never reached the application correctly.
Where Java-related logs are usually stored in Plesk
In a standard Plesk-based hosting environment, Java-related logs are typically found in one or more of the following places:
- Application server logs for Tomcat, JVM, or custom Java services
- Domain logs for web traffic, HTTP errors, and application access
- Plesk service logs for extension actions, service control, and provisioning events
- System or runtime logs if the host exposes them for managed troubleshooting
If you are using a Java hosting setup with a private JVM or a dedicated Tomcat instance inside your hosting account, the most important logs are usually the Tomcat catalina log, the application’s own log files, and the domain error log. These files help you understand whether the issue is with deployment, configuration, permissions, Java version compatibility, or application code.
Check the My App Server or Tomcat log location first
If your hosting plan includes a Java extension such as My App Server, start with the service itself. This is where startup and runtime messages are usually written. A Tomcat-based service often records:
- server startup and shutdown events
- Java version and JVM initialization details
- WAR deployment messages
- port binding issues
- context loading errors
- stack traces from application exceptions
Common file names may include:
catalina.outcatalina.<date>.loglocalhost.<date>.logmanager.<date>.log- custom application logs created by the app itself
In a managed hosting setup, these logs are often inside the application server directory under your account or service workspace. The exact folder can vary depending on how the Tomcat instance was installed, whether it is a ready-to-use version, or whether you uploaded and configured a custom app server manually.
How to identify the correct server log
If you are not sure which file is relevant, open the newest log first and look for:
- ERROR or SEVERE lines
- stack traces containing
ExceptionorCaused by - messages mentioning
bind,port,startup, ordeploy - Java class loading failures or missing libraries
For Tomcat hosting and servlet hosting, startup logs are especially useful when an application fails immediately after deployment. If the app starts but later returns a 500 error, the application log and the domain error log will usually provide more detail.
Find domain logs in Plesk
Plesk keeps domain-level logs that help you diagnose web requests reaching your Java application. These logs are useful when the app server is running but the site still does not respond correctly. They can show HTTP status codes, request paths, proxy issues, and errors at the web server layer.
Look for domain logs in the hosting panel under the website or domain management area. Depending on the Plesk setup, you may see:
- access logs
- error logs
- web server logs for Apache or nginx
For Java hosting, these logs help you distinguish between:
- a problem in Apache/nginx routing
- a problem in Tomcat or the JVM
- a problem in the application code itself
If the domain log shows a 502 or 503 error, the web server may not be able to reach the Java service. If it shows a 500 error, the request likely reached the application but failed during processing. If there is no meaningful request entry at all, the domain may not be pointing to the correct document root or proxy target.
Use the Plesk interface to open logs faster
Plesk usually provides a convenient way to view logs without connecting to the server manually. This is especially helpful in managed hosting environments where you may not have SSH access or where the platform is designed to keep technical work inside the control panel.
To find logs in Plesk, follow these general steps:
- Log in to Plesk.
- Open the relevant domain or subscription.
- Go to the section related to logs, statistics, or domain management.
- Review the most recent entries first.
- Filter by status code, time window, or file type if the interface allows it.
Some hosting providers also show recent log snippets directly from the domain overview page. This can be enough to identify the first error in a Java deployment. If the control panel includes a file manager, you may also be able to browse the application directory and open the log file directly.
What to search for inside the log viewer
When reviewing logs in Plesk, search for common Java and Tomcat markers such as:
SEVEREExceptionStackTraceServletExceptionClassNotFoundExceptionOutOfMemoryErrorBindException
These terms usually point to the real cause instead of the symptom. For example, a browser error may only show that the site failed, while the log reveals that a required library is missing or that the JVM ran out of memory during startup.
How Java logs differ from Apache and nginx logs
When troubleshooting a Java application in Plesk, it is important to separate web server logs from Java runtime logs. Apache and nginx record what happens at the HTTP layer, while Tomcat and the JVM record what happens inside the application platform.
Apache or nginx logs may show:
- client requests
- status codes such as 404, 500, 502, or 503
- proxy connection failures
- rewrite or routing issues
Tomcat or JVM logs may show:
- application startup failures
- deployment unpacking problems
- missing classes or jars
- Java compatibility issues
- runtime exceptions in servlets or JSP pages
When a Java site is down, start with the HTTP error seen by the visitor, then move inward to the server logs. This approach makes it easier to locate the exact layer where the failure occurs.
Typical log paths in a Java hosting setup
The exact file path depends on your account structure and the way the Java service was installed. In a shared hosting environment with a private Tomcat instance, the logs are commonly stored near the application server installation directory or inside the user space associated with the domain.
Examples of log locations you may encounter include:
- the Tomcat
logsdirectory - a domain-specific application folder
- a separate service directory created by the hosting platform
- rotated log archives with date-based names
If your provider uses a custom Plesk extension for Java hosting, the logs may be organized by service name, domain, or application instance rather than by the standard system path. This is normal in managed hosting because the provider often isolates each account’s service files for security and easier maintenance.
Common file types you may see
- Plain text logs for runtime and error messages
- Rotated logs with date stamps for historical troubleshooting
- Access logs showing incoming requests
- Error logs showing failed requests or configuration issues
- Application-specific logs created by frameworks such as Spring, Struts, or custom Java code
What to do when no Java log is visible
Sometimes you may not see a Java-specific log in the place you expect. In that case, check the following:
- the application server may not have started yet
- logging may be redirected to a different directory
- the app may write logs only after the first request
- file permissions may prevent log creation
- the Java version or service configuration may be invalid
If you recently changed the Java version, restarted the service, or uploaded a new WAR file, check whether the server created a new log file after the next start attempt. If nothing appears, the issue may happen before the service can initialize logging.
Also confirm that the application has permission to write to its log directory. In a managed hosting environment, write access is usually restricted to the account’s allowed paths. If permissions are too narrow, the application may start partially or fail to record useful diagnostic data.
Troubleshooting Java deployment problems with logs
Logs are especially useful after deploying a WAR file or updating a servlet-based application. A successful deploy does not always mean the application is healthy. The server may unpack the archive but still fail when loading classes or initializing the servlet context.
Look for these common messages:
- ClassNotFoundException — a required class or library is missing
- NoClassDefFoundError — a class was found at compile time but not at runtime
- UnsupportedClassVersionError — the app was compiled with a newer Java version than the server provides
- BindException — the port is already in use
- OutOfMemoryError — the JVM does not have enough memory for the current load
- ServletException — the servlet failed during request processing or initialization
For JSP hosting and servlet hosting, classpath and library problems are among the most common causes of startup errors. The log usually points to the first missing dependency, which is more useful than the final failure message shown in the browser.
How to use logs safely in a managed hosting environment
Log files can contain technical details about paths, application names, request data, and internal error traces. When sharing logs with support, include only the relevant lines and avoid sending unnecessary personal or sensitive data.
Good practice includes:
- copying the exact error lines around the failure
- including timestamps
- noting what action triggered the issue
- mentioning the Java version and application server version
- redacting credentials, tokens, or private URLs if present
If your hosting provider offers support for My App Server or Tomcat management, a short excerpt from the log is often enough to identify whether the issue is related to deployment, JVM settings, or application code.
Best practices for Java log troubleshooting in Plesk
To make future troubleshooting easier, keep your Java environment consistent and well documented. A few simple habits can save a lot of time later.
- Note which Java version is used by each application.
- Keep track of the Tomcat or custom app server version.
- Use clear names for WAR files and application contexts.
- Check logs immediately after deployment.
- Review both server logs and domain logs when an error occurs.
- Rotate or archive logs regularly if your hosting plan allows it.
If you maintain multiple Java applications in one account, create a small checklist for each site: where the app runs, which Java version it uses, where its logs are stored, and what the normal startup messages look like. This makes it much easier to compare the current state with a known-good setup.
When to contact support
If you have checked the Tomcat logs, domain logs, and Plesk log viewer but still cannot identify the issue, contact support with the relevant error excerpt. This is the best next step when the problem appears to involve the hosting environment rather than the application code alone.
Contact support if you see any of the following:
- the Java service does not start at all
- the log file is missing or not updating
- the service starts but the domain returns 502 or 503 errors
- you suspect a Java version mismatch
- the app works after deploy but fails under normal requests
For managed Java hosting, support can often confirm the correct log path, check service status, and verify whether the app server is running with the expected Java runtime.
FAQ
Where are Tomcat logs in Plesk?
Tomcat logs are usually located inside the application server’s log directory or the Java service workspace. In a My App Server setup, they may also be accessible through the hosting panel or stored under the domain’s service files.
Which log should I check first for a Java error?
Start with the Tomcat or JVM startup log, then review the domain error log. If the app is failing after a web request, the access and error logs can show whether the request reached the application server.
Why do I see a 500 error but no Java exception in the browser?
The browser usually shows only the HTTP status, not the full cause. The real exception is usually in the Tomcat log, the application log, or the Plesk error log.
Can I use logs to debug WAR deployment problems?
Yes. Logs are one of the best ways to debug WAR deployments. They often show unpacking errors, missing classes, invalid configuration, or Java version incompatibilities.
What if my custom Java app server writes logs somewhere else?
That is possible. Custom app servers can use a different log directory or file name. Check the server configuration, the application settings, or the hosting provider’s Java service documentation.
Do I need SSH access to view Java logs?
Not always. Many Plesk installations let you view recent logs from the control panel. SSH is useful for deeper troubleshooting, but basic log review can often be done directly in Plesk.
Summary
To find Java-related logs in Plesk, check the Tomcat or My App Server logs first, then review the domain access and error logs. In a Java hosting environment, these files work together: the web server shows the request path and HTTP status, while the Java runtime shows what failed inside the application. If you are using a private JVM, Tomcat hosting, JSP hosting, or servlet hosting service, the logs are the most reliable source for diagnosing deployment issues, startup errors, and runtime exceptions.
When in doubt, look for the newest log entries, focus on SEVERE and exception lines, and compare the error time with the request time. That approach usually leads you to the root cause much faster than checking the browser error alone.