When a Tomcat application does not start correctly, the fastest way to find the cause is usually in the logs. A startup failure can come from an invalid Java version, a broken WAR deployment, a port conflict, a missing environment variable, a permissions issue, or an application error during initialisation. In a managed hosting environment, especially when you run Tomcat through a control panel such as Plesk with a service like My App Server, logs are the main source of truth for understanding what happened during startup.
This guide explains how to read Tomcat startup logs, where to find the relevant files in a hosted Java environment, which error patterns matter most, and how to narrow down the root cause quickly. It is written for hosted Tomcat, JSP, servlet and Java applications running in a private JVM or controlled service setup.
Where to look first when Tomcat will not start
In most Tomcat hosting setups, startup problems appear in one or more of these places:
- Tomcat catalina log
- stdout and stderr output from the Java process
- Application logs created by your app
- Control panel or service logs in Plesk / My App Server
- System or service status messages if the service failed to launch at all
If your hosting platform provides a service control screen, check the service status first. If the service is shown as stopped, failed, or restarting repeatedly, the log files will usually explain why. If the service is running but the site shows an error, the issue may be inside the application rather than the Tomcat service itself.
Understand the startup sequence in Tomcat
Before reading logs, it helps to know the normal startup flow. A typical Tomcat start goes through these stages:
- The JVM starts.
- Tomcat initialises its configuration.
- Connectors and ports are opened.
- Web applications are deployed.
- Servlets, filters, listeners and frameworks are initialised.
- The server becomes ready to serve requests.
A failure can happen at any step. A port conflict usually breaks startup early. A deployment or framework error often appears later, when the application is being loaded. Knowing roughly when the failure occurs helps you read the log in the right section instead of searching blindly.
Find the right log file for the problem
In a managed hosting environment, Tomcat logs may be separated by service instance, application, or user account. If you are using My App Server in Plesk, check the service-related log access in your control panel first. Depending on the setup, you may see:
- service logs for the Tomcat instance
- application logs under the app directory
- Java process output captured by the hosting platform
- Apache proxy logs if the request is forwarded through Apache
For troubleshooting startup problems, the most useful log is usually the one that contains the last messages before the process stopped or restarted. If the service starts and then immediately exits, search for the first SEVERE, ERROR, or stack trace entries around the same timestamp.
Common log names you may see
- catalina.out or similar output file
- catalina.YYYY-MM-DD.log
- localhost.log
- manager or application-specific logs
- stderr.log / stdout.log
Names can vary by setup, but the purpose is the same: one file records the Tomcat lifecycle and another records the application’s own messages.
What to search for in a Tomcat startup log
When reading logs, do not try to understand every line. Focus on patterns that indicate failure, such as:
- SEVERE
- ERROR
- Exception
- Caused by
- Stack trace
- BindException
- ClassNotFoundException
- NoClassDefFoundError
- OutOfMemoryError
- UnsupportedClassVersionError
The most important part is usually the first real error in the chain. Many stack traces contain several follow-up errors, but one root exception usually causes the entire startup failure.
How to read a stack trace correctly
A Java stack trace is read from top to bottom, but the root cause is often near the bottom after Caused by. For example:
- The top may show a generic startup failure.
- The middle may show framework classes or Tomcat internals.
- The bottom may show the actual problem, such as a missing file, bad configuration, or incompatible class.
If you only read the first line, you may miss the real cause. Always scan down to the deepest Caused by entry.
Use log timestamps to match the failure moment
Startup logs are easier to interpret if you identify the exact time when Tomcat stopped progressing. Compare the timestamps of:
- the last successful Tomcat message
- the first warning or error
- the moment the service restarted or stopped
If the log shows deployment started at 10:14:02 and the failure appears at 10:14:07, you know the issue is probably in application initialisation, not the JVM launch itself. This is particularly helpful in hosted environments where multiple services are running and several logs may be updating at the same time.
Typical log patterns and what they mean
1. Port already in use
If Tomcat cannot bind to its HTTP, HTTPS, or shutdown port, startup usually ends quickly. You may see messages such as BindException or Address already in use.
What this usually means:
- another process is already using the port
- the service was started twice
- the Tomcat configuration was changed to a conflicting port
In a Plesk-based hosting setup, port management is often handled for you, but a custom Tomcat instance or manually uploaded version can still conflict if the configuration is changed incorrectly.
2. Java version mismatch
A common startup issue is an incompatible Java runtime. The log may show UnsupportedClassVersionError or class loading failures after deployment starts.
This usually means:
- the application was compiled with a newer Java version than the installed runtime
- the selected Java version in the hosting control panel does not match the application requirements
- a library requires a newer JVM feature
If your hosting platform lets you choose from several ready-to-use Java or Tomcat versions, verify that the selected version matches your app’s build target.
3. Missing classes or libraries
Errors like ClassNotFoundException and NoClassDefFoundError are often caused by missing JAR files, wrong deployment structure, or libraries not included in the WAR package.
Common causes include:
- the application depends on a library that is not deployed
- a JAR was placed in the wrong folder
- the application expects a class from a framework that is not available in the runtime
In a hosted Tomcat environment, verify that all required dependencies are included in the application package or available in the correct classpath location.
4. XML or configuration syntax errors
If the log points to a broken XML file, invalid context configuration, or malformed properties file, Tomcat may stop during startup or fail to deploy the web app.
Look for messages like:
- parsing errors
- unexpected end of file
- invalid attribute
- cannot load configuration
Small syntax errors can block the full application from starting. A single incorrect character in a deployment descriptor or context file is enough to prevent successful startup.
5. Permission problems
If the application cannot read or write files, create temporary data, or access its deployment directory, the log may show access denied messages or file system errors.
Typical signs:
- cannot open file
- permission denied
- failed to create directory
- cannot write to log or temp location
This is common when the app expects a writable directory that has not been configured correctly for the hosting account.
6. OutOfMemoryError during startup
If Tomcat or the application needs more memory than available in the configured JVM, startup may fail with OutOfMemoryError or become unstable during deployment.
Possible signs include:
- the JVM exits abruptly
- garbage collection warnings appear before failure
- the service restarts repeatedly
In shared hosting or private JVM setups, memory limits are important. If the application is too large for the assigned resources, you may need to reduce its footprint or review the app design.
Step-by-step method to troubleshoot a startup problem with logs
Step 1: Confirm the service state
Open the control panel or service management section and check whether the Tomcat instance is stopped, failed, or restarting. If there is a service control option, note the exact action result. This helps you determine whether the issue is a start command problem, a runtime crash, or an application deployment failure.
Step 2: Open the most recent log entries
Review the latest log lines around the time you tried to start Tomcat. If the service has multiple logs, begin with the main Tomcat output log and then move to the application log.
Step 3: Find the first error
Ignore repeated follow-up messages at first. Search for the earliest:
- SEVERE
- Exception
- Caused by
- ERROR
The first error usually points to the true cause. Later errors may only reflect the fact that Tomcat could not complete startup.
Step 4: Match the error to a category
Ask whether the issue is related to:
- Java runtime compatibility
- port configuration
- missing dependencies
- broken deployment files
- permissions or storage access
- resource limits such as memory
This step helps you avoid random changes. Fix the category that the log actually points to.
Step 5: Restart only after a targeted change
After you make one clear change, restart the service and re-check the log. If the same error remains, you have not yet addressed the root cause. Change one thing at a time so you can verify what actually helped.
How logs help in a My App Server / Plesk Tomcat setup
When you use a managed Java hosting platform with a control panel, logs are especially useful because they connect the application, the JVM, and the service layer in one place. With My App Server, you can typically manage a private Tomcat or Java runtime without needing direct server administration. That makes logs the main diagnostic tool when the application fails to start.
In this kind of setup, logs can help you:
- confirm which Java version is active
- see whether the Tomcat service launched successfully
- identify deployment errors in your WAR or exploded application
- verify whether a restart fixed the issue
- check whether the problem is in Tomcat itself or in your app
If you are using a custom app server configuration, logs are even more important because manual changes may affect JVM options, classpath, or startup scripts.
Useful examples of startup log messages
Below are examples of the types of log entries that often explain a startup failure:
- BindException: Address already in use — port conflict
- UnsupportedClassVersionError — Java version mismatch
- ClassNotFoundException — missing class or dependency
- NoClassDefFoundError — class not available at runtime
- FileNotFoundException — missing path or incorrect file reference
- AccessDeniedException — permissions issue
- OutOfMemoryError — JVM memory exhaustion
- LifecycleException — Tomcat failed during startup or deployment
These messages are not always the root cause on their own, but they are strong indicators of where to investigate next.
What to do after you identify the cause
Once the log points to a likely reason, make the smallest possible correction and test again. Examples:
- change the Java version to match the application
- fix a port setting in the Tomcat configuration
- rebuild and redeploy the WAR file
- add the missing library to the application package
- correct file permissions or writable paths
- adjust JVM memory settings within the hosting limits
If you are not sure which change is safe, keep a copy of the original configuration before modifying it. That makes rollback easier if the new setting does not solve the problem.
Best practices for diagnosing startup issues from logs
- Check the log immediately after each start attempt.
- Focus on the first error, not the last one.
- Compare timestamps across Tomcat and application logs.
- Keep the deployment package clean and consistent.
- Use the Java version recommended for your application.
- Do not assume a service failure is always a code bug; it may be configuration.
- Document any change you make before trying again.
In hosted environments, this approach saves time and reduces the risk of making multiple changes that hide the real cause.
When the logs do not show enough information
Sometimes the visible log is too short or ends before the error appears. In that case:
- check whether another log file contains the missing lines
- look for application-specific logs in the deployed app directory
- verify that logging is enabled at an appropriate level
- confirm the service actually had permission to write logs
- inspect the deployment package for obvious configuration problems
If logs are missing entirely, the service may be failing before the logging subsystem starts. That often points to an environment or JVM-level issue rather than an application bug.
FAQ
Why does Tomcat start and then stop immediately?
This usually means the JVM launched, but Tomcat or the application hit a startup error during initialisation. Check the log for the first exception, especially around port binding, class loading, or deployment.
Which log file should I check first for a Tomcat startup problem?
Start with the main Tomcat output or catalina log, then check stdout, stderr, and application logs. In a control panel environment, also review the service log shown in the hosting interface.
What does Caused by mean in a Java log?
It usually shows the underlying reason for a higher-level exception. The deepest Caused by line is often the real root cause of the startup problem.
Can a wrong Java version stop Tomcat from starting?
Yes. If the application or one of its libraries was built for a newer Java release than the installed runtime, startup can fail with class version or compatibility errors.
How do I know if the problem is in Tomcat or in my application?
If Tomcat itself fails before deploying the app, the issue is likely in service configuration, Java runtime, ports, or environment settings. If Tomcat starts but one application fails to deploy, the problem is usually inside the application package or its dependencies.
Do I need direct server access to troubleshoot logs?
Not always. In a managed hosting setup with Plesk and My App Server, the relevant logs are often available from the control panel. That is usually enough to diagnose common startup issues.
Conclusion
Reading Tomcat logs is the most reliable way to troubleshoot startup problems in a hosted Java environment. Instead of guessing, use the log timestamps, the first error, and the stack trace to identify whether the issue is related to Java version compatibility, ports, missing libraries, permissions, configuration syntax, or memory limits. In a Plesk-based hosting setup with My App Server, this process is especially practical because the control panel, service management, and application runtime are closely connected.
Once you learn to recognise the common error patterns, Tomcat startup failures become much easier to diagnose and fix. Start with the main service log, confirm the exact failure point, make one targeted change, and test again. That is the most efficient way to restore your Java application quickly and safely.