If your Tomcat application stops responding, returns a 500 error, or behaves differently after a deploy, the fastest way to find the cause is usually in the application logs. In a managed hosting environment, Tomcat logs often tell you whether the problem is in your WAR deployment, a missing class, a configuration mismatch, a startup failure, or an exception thrown by your application code.
When you host Java applications with a control panel such as Plesk and a managed Tomcat setup like My App Server, log reading is especially useful because it helps you separate application issues from service issues. You can quickly see whether Tomcat started correctly, whether the JVM is healthy, and whether your app is failing during initialization, request handling, or shutdown.
Where Tomcat application logs are usually found
Tomcat writes several kinds of logs, and knowing which one to check saves time. The exact location can vary depending on how the service is installed and managed, but in a typical Tomcat hosting setup you should look for:
- catalina.out or the main console log, which often contains startup messages and unhandled output from the JVM.
- catalina.YYYY-MM-DD.log, which contains container-level messages for a specific day.
- localhost.YYYY-MM-DD.log, which often includes application and webapp messages.
- manager, host-manager, or access logs, if those components are enabled.
- application-specific logs, if your app writes its own log files using Log4j, Logback, java.util.logging, or a similar framework.
In a Plesk-managed Java hosting environment, these logs may be accessible from the service control area or through the file manager, depending on the setup. If your hosting platform uses a private JVM and a separate Tomcat instance per account or service, the logs are typically isolated from other users, which makes troubleshooting much easier.
Start with the symptom, then match it to the log
Before opening the logs, identify what is actually wrong. Different symptoms usually point to different log patterns.
Common symptoms and what they often mean
- HTTP 500 error on one page — often an exception in application code or a missing resource.
- Application does not load after deploy — frequently a deployment error, classpath problem, or startup failure.
- Tomcat restarts or stops unexpectedly — may indicate JVM memory pressure, a crash, or a service configuration issue.
- Login or database features fail — usually an application exception, network problem, or bad configuration.
- Application works locally but not on hosting — often due to version mismatch, file permission issues, or missing environment settings.
Once you know the symptom, open the logs around the time the problem occurred. That simple step eliminates a lot of noise.
How to read Tomcat logs effectively
Tomcat logs can look intimidating at first, but most entries follow the same pattern: timestamp, log level, component name, and message. The message may include an exception stack trace, which is usually the most valuable part.
1. Check the timestamp first
Find the exact time when the issue happened. Then inspect entries a few minutes before and after that time. Many errors are preceded by a warning or by an earlier exception that caused the visible failure later.
If you are troubleshooting a deploy, check the log from the moment the WAR was uploaded or the application service was restarted. If you are troubleshooting a runtime issue, use the time of the failed request or user report.
2. Focus on ERROR and SEVERE messages
Most logs include different severity levels such as INFO, WARN, ERROR, and SEVERE. For troubleshooting, start with:
- SEVERE — usually important container or application failures.
- ERROR — application or service errors that need attention.
- WARN — warnings that can help explain later failures.
INFO lines are still useful because they show startup flow, deployment progress, and service lifecycle events. However, the root cause is often hidden in a later ERROR line or in the stack trace that follows it.
3. Read the first meaningful exception, not only the last line
In Java logs, a stack trace often contains multiple nested exceptions. The final line may only say something general like “Servlet exception” or “Application startup failed.” The real cause is usually higher up in the trace, where you may see:
- Caused by: lines
- ClassNotFoundException
- NoSuchMethodError
- NullPointerException
- SQLException
- BindException or port-related errors
The first exception in the chain is often the most important one. The later exceptions are frequently just the result of that original failure.
Typical log patterns and what they mean
Below are some common Tomcat log patterns you may see in a managed hosting environment.
Startup problems
If Tomcat or your application fails during startup, the logs often include messages such as:
- Deployment failed
- Context initialization failed
- Cannot load servlet class
- Error parsing web.xml
- Failed to start component
These usually point to a problem in the application package itself, a bad configuration file, or a dependency that is missing from the WAR. In a private Tomcat hosting setup, startup errors are especially common after a new deployment, after a Java version change, or after updating a library.
Class loading and dependency errors
Messages like ClassNotFoundException or NoClassDefFoundError indicate that Tomcat cannot find a class the application expects. Common reasons include:
- a missing JAR file in the application package
- an incorrect build configuration
- a library compiled for a different Java version
- a dependency conflict between bundled libraries and server libraries
If you are using My App Server, check whether the application was deployed with the correct Java version and whether the WAR contains all required dependencies. For hosted Java applications, this type of problem is often fixed by rebuilding the app and redeploying it cleanly.
Servlet and JSP errors
For JSP hosting and servlet hosting, log entries may show compilation issues, missing classes, or syntax problems in JSP files. Look for:
- JSP compilation errors
- Servlet initialization failures
- Template parsing errors
- IllegalStateException during request processing
If a specific page fails but the rest of the application works, the error is often in a JSP, controller, or action class rather than in Tomcat itself.
Database connection failures
Application logs often reveal database issues through stack traces involving SQL exceptions, connection pool errors, timeouts, or authentication failures. You might see messages like:
- Connection refused
- Access denied
- Too many connections
- Timeout waiting for connection
- Unable to acquire JDBC connection
When this happens, check whether the database credentials are correct, whether the database host is reachable, and whether the connection pool settings are appropriate for the application size.
Memory pressure and out-of-memory situations
If the JVM runs out of memory, the logs may show OutOfMemoryError, garbage collection warnings, or abrupt shutdown messages. In a shared hosting account with a private JVM, this usually means the application needs to be optimized, the heap settings need adjustment, or the app is using too much memory for the current service limits.
Do not assume that a memory error always means Tomcat is broken. In many cases, the application is holding too many objects, loading too much data at once, or leaking resources between requests.
How to troubleshoot a failed deploy using logs
After a WAR deploy, read the log from the exact moment the deployment started. In a managed Tomcat hosting environment, the deployment process should usually be visible in the logs as the context is loaded and initialized.
Step-by-step deploy troubleshooting
- Note the deploy time from the control panel or file upload time.
- Open the main Tomcat log and the application log around that time.
- Look for startup messages and then for the first ERROR or SEVERE line.
- Read the full stack trace and identify the first Caused by section.
- Check whether the issue is a missing file, bad class, invalid configuration, or Java version mismatch.
- Fix the application package and redeploy cleanly.
If the log shows successful deployment but the app still returns errors, the problem may be in request handling rather than startup. In that case, check the logs when you open the affected page or send the failing request.
How to distinguish Tomcat issues from application issues
This distinction matters in hosting support because it changes the next step. Tomcat itself may be healthy while the application is failing.
Signs of a Tomcat-level problem
- The service fails to start at all.
- The log shows port binding issues, JVM startup errors, or container initialization failures.
- All hosted apps on that Tomcat instance fail in the same way.
- The service stops and restarts repeatedly.
Signs of an application-level problem
- Tomcat starts normally, but one app fails.
- Only specific pages or endpoints return errors.
- The logs show application exceptions after a request is received.
- Other webapps on the same service continue to work.
In My App Server environments, this split is very practical because you can often manage the service separately from the deployed application. That makes it easier to restart the Java service, redeploy the WAR, or switch Java versions without affecting unrelated hosting services.
What to look for in stack traces
Stack traces are the most useful part of the log when something fails inside the application code. A good reading method is to move from the top to the bottom and then back up to the first cause.
Useful things to identify
- The exception type — for example NullPointerException or SQLException.
- The class name — this tells you where the error originated.
- The method name — often points to the exact code path.
- The message text — may include missing files, invalid values, or auth failures.
- The first Caused by — often the true root cause.
For example, if you see a long trace ending in a servlet error, but earlier there is a database authentication failure, then the database issue is the real problem. The servlet error is only the result.
Useful checks in a Plesk-managed Java hosting environment
When Tomcat runs through a control panel and a custom service management layer, a few extra checks help narrow the problem faster.
- Confirm the correct Java version is selected for the service.
- Check whether the Tomcat service is running or was restarted recently.
- Review the deploy status after uploading a WAR file.
- Verify that the application path matches the configured context.
- Check file permissions if the app cannot read configuration or write logs.
- Review any service limits that could affect memory or process behavior.
For hosted apps using a private JVM, a wrong Java version is a common source of problems. Logs may show syntax or class compatibility errors immediately after startup if the application was built for a different runtime.
Practical log-reading workflow
If you need a simple routine, use this workflow each time an application fails:
- Identify the exact failure time.
- Open the main Tomcat log and the application log.
- Search for ERROR, SEVERE, exception, and Caused by.
- Read a few minutes before the failure, not only the failure line itself.
- Note the first root-cause exception.
- Compare the stack trace with recent changes, such as a new deploy or config update.
- Retry the action after fixing the issue and confirm the error no longer appears.
This method works well for JSP, servlet, and WAR-based applications because it follows the same pattern regardless of the framework.
Examples of log clues and likely action
Example 1: Class not found during startup
Likely meaning: A dependency is missing from the deployed app.
What to do: Rebuild the WAR, verify all required JAR files, and redeploy.
Example 2: SQLException after login
Likely meaning: The app cannot reach the database or credentials are wrong.
What to do: Check database host, username, password, connection pool settings, and network access.
Example 3: OutOfMemoryError during heavy traffic
Likely meaning: The JVM heap is too small or the application leaks memory.
What to do: Review memory usage, reduce app load, and adjust JVM settings within the service limits.
Example 4: JSP compilation error
Likely meaning: There is a syntax issue in the JSP or an unsupported library reference.
What to do: Open the JSP source, fix the code, and redeploy.
When the log is not enough
Sometimes logs show the symptom but not the complete cause. If that happens, combine log reading with:
- recent code changes
- the deployment package contents
- service status in the control panel
- browser error details
- database logs, if relevant
- access logs, if you need to confirm the request path
In managed hosting, this combined approach is usually faster than guessing. The log tells you where to look; the application and control panel tell you what changed.
FAQ
Which Tomcat log should I check first?
Start with the main Tomcat console or catalina log, then check the application log for the same time period. If the issue is request-specific, also review any app-specific logs.
What if the log only shows a generic 500 error?
Look earlier in the log for the first exception or a warning that happened just before the 500 response. The generic error is often only the last visible symptom.
How do I know whether the problem is in Tomcat or my application?
If Tomcat starts and only one app fails, the problem is usually in the application. If the service itself cannot start or all apps fail, the issue is more likely at the Tomcat or JVM level.
Why does the application work locally but fail on hosting?
The most common reasons are a different Java version, missing dependencies, file permission differences, or configuration values that are not present in the hosted environment.
Can I use logs to troubleshoot a WAR deployment issue?
Yes. Deployment logs usually show whether the WAR unpacked correctly, whether the context started, and which exception stopped initialization.
What should I do if the logs are too large?
Filter by timestamp, log level, or keywords such as ERROR, SEVERE, Exception, and Caused by. Start from the exact failure time instead of reading the entire file.
Conclusion
Reading Tomcat application logs is one of the most effective ways to diagnose problems in Java hosting. In a Plesk-managed environment with My App Server, logs help you quickly identify whether the failure is related to deployment, Java version compatibility, missing dependencies, database access, memory limits, or application code.
The key is to focus on the exact failure time, read the first meaningful exception, and separate Tomcat-level issues from application-level issues. With that approach, most common hosting problems become much easier to resolve, especially for WAR, JSP, and servlet-based applications running on a private Tomcat instance.