If a Tomcat application in your hosting account does not start, the fastest way to find the cause is usually in the logs. In a managed hosting environment with Plesk and a private JVM, startup problems often come from a small set of issues: a Java version mismatch, a broken WAR deployment, a port conflict, missing permissions, an invalid context path, or an application exception during initialization. Reading the right log files in the right order can save a lot of time and help you fix the problem without guesswork.
This guide explains how to use application logs to troubleshoot a Tomcat startup problem in a UK hosting context, with practical steps for customers using a control panel and a Java hosting solution such as My App Server. The same approach works whether you deploy a WAR file, run a JSP/servlet application, or manage a private Tomcat instance inside a shared hosting account.
What to check first when Tomcat does not start
Before going deep into log analysis, confirm the basic service status and deployment setup. In a control panel such as Plesk, the app server may fail to start because of configuration rather than because of the code itself.
- Check whether the Tomcat service is stopped, starting, or running with errors.
- Verify that the selected Java version matches your application requirements.
- Confirm that the WAR file or application directory was uploaded correctly.
- Make sure the app server has enough disk space and quota available.
- Review whether any recent changes were made to the application, context path, or server settings.
In many cases, the first visible symptom is only that the application does not respond. The actual reason is usually recorded in the logs a few seconds earlier.
Which logs matter for Tomcat startup problems
When troubleshooting a Tomcat startup issue, do not rely on only one log file. The most useful logs are usually the Tomcat startup log, the application log, and the service control log from the hosting panel. Depending on the setup, you may also need the Apache error log if the app is served behind Apache or a proxy.
Tomcat or application server startup log
This log records the startup sequence, deployment of web applications, connector initialization, and most fatal errors that stop Tomcat from starting correctly. Look for lines containing words such as SEVERE, Exception, BindException, ClassNotFoundException, or FAILED.
Application log
Your web application may write its own log file through a logging framework such as log4j, Logback, or java.util.logging. If the application starts but crashes during initialization, the application log often contains the real root cause, such as a missing configuration file, database authentication error, or a bad environment value.
Service control log
In a managed control panel environment, service actions such as start, stop, restart, and redeploy can generate their own control log. This is useful when the service fails before Tomcat fully initializes, because the panel log may show whether the failure is due to a timeout, a permission issue, or a service-level problem.
Apache error log
If your Java app is exposed through Apache, the Apache error log can show proxy errors, backend connection failures, or issues with the reverse proxy configuration. This is especially useful when Tomcat starts, but the website still returns 502, 503, or a gateway timeout.
How to read the logs in the right order
When a Tomcat startup fails, read the logs from the top of the relevant error window, not only from the bottom where the final failure appears. The first warning often points to the real cause, while the last error is only a consequence.
- Open the Tomcat startup log and find the time of the failed start attempt.
- Scan for the first SEVERE or ERROR message around that time.
- Check whether there is a stack trace and identify the first exception in the chain.
- Compare the same timestamp in the application log.
- If needed, check the service control log and Apache error log for related messages.
A practical method is to focus on three questions:
- What was Tomcat doing just before it stopped?
- Which class, file, port, or dependency caused the failure?
- Is the problem inside the application, in the server configuration, or in the hosting environment?
Common log patterns and what they mean
Different startup errors produce different log patterns. Recognizing these patterns helps you move faster from symptom to fix.
Port already in use
If the log contains a message like Address already in use or BindException, Tomcat is trying to use a port that is already taken. In a hosting account with a private JVM, this may happen after a failed restart or after a conflicting manual configuration.
What to do:
- Check whether another process is using the same port.
- Review the Tomcat connector configuration.
- Use the control panel service tools to restart the app server cleanly.
- If a custom app server was uploaded manually, verify that its ports do not clash with existing services.
Java version mismatch
If the log mentions an unsupported class file version, incompatible bytecode, or missing modules, the app may have been built for a newer Java version than the server is using. This is a common issue when deploying a WAR that was compiled on a different JDK.
What to do:
- Check the Java version selected for the app server.
- Compare it with the version used to build the application.
- Switch to a compatible version if your hosting plan allows it.
- Rebuild the application for the target Java version if needed.
Class loading or missing library errors
Messages like ClassNotFoundException, NoClassDefFoundError, or UnsatisfiedLinkError usually mean that a required library is missing or not loaded correctly. This often happens after uploading a WAR with incomplete dependencies or after removing a jar file that the application still expects.
What to do:
- Check the WEB-INF/lib directory inside the application package.
- Compare the deployed files with your build output.
- Confirm that the application is not relying on a jar that exists only in your local environment.
- Look for path differences between development and hosting.
Permission denied or file access errors
If the log shows Permission denied, Access is denied, or file read/write errors, Tomcat may not have the necessary permissions to access a directory, create a temp file, or write to a log path. In a hosted environment, this can happen after uploading files with incorrect ownership or after changing directory settings.
What to do:
- Check file and folder permissions for the application directory.
- Confirm that the Tomcat process can write to temp and log locations.
- Avoid hardcoded absolute paths that point outside the allowed hosting area.
- Review recent file uploads or deploy changes.
Application initialization exception
If Tomcat starts but the webapp fails during deployment, the log may contain a long stack trace ending in a servlet initialization error, bean creation error, or database connection failure. This usually means the server itself is fine, but the application cannot complete its startup logic.
What to do:
- Inspect the first exception in the stack trace.
- Check configuration files for missing values or bad syntax.
- Test database credentials, connection URL, and driver availability.
- Verify environment variables or system properties used by the app.
OutOfMemoryError or resource limits
A startup failure with OutOfMemoryError, GC overhead limit exceeded, or similar messages can indicate that the application needs more memory than available in the current JVM settings. In shared or managed hosting, memory is limited by the service configuration, so a large application may need tuning or a smaller runtime footprint.
What to do:
- Check the JVM memory settings used by the app server.
- Reduce startup-time workload if possible.
- Review any large libraries, caches, or eager-loading components.
- If the application is too heavy for the current setup, simplify the deployment or optimize it before increasing resource usage.
Step-by-step troubleshooting workflow using logs
The most efficient approach is to use the logs as a decision tree. Start from the failed start attempt and narrow the issue down by eliminating layers.
1. Identify the exact time of the failed start
Find the moment when you clicked start, redeployed the application, or restarted the service. Match that timestamp in the logs. This prevents confusion when the log contains older errors from previous attempts.
2. Look for the first meaningful error
Do not stop at the final error line. Scroll slightly above it and search for the first exception, warning, or configuration message. The actual root cause may appear several lines earlier.
3. Separate server errors from application errors
If the log fails before the webapp is deployed, the issue is usually server-level: port, Java, permissions, or service config. If the server starts but the app fails, the issue is more likely inside the application package, database setup, or framework configuration.
4. Compare with the deployment method
If you installed Tomcat using a one-click option in My App Server, check whether the selected version matches the app. If you uploaded a custom app server manually, confirm that the configuration files, startup scripts, and Java version are aligned with the application requirements.
5. Test after each change
Make one fix at a time, then restart and re-check the logs. Changing multiple things at once makes it harder to determine which fix solved the issue.
How My App Server and Plesk help with log-based troubleshooting
In a hosting control panel environment, having a dedicated Java hosting extension such as My App Server makes startup troubleshooting easier because you can manage the service, Java version, and deployment from one place. For small and medium Java applications, that control is often enough to isolate most startup problems quickly.
- You can install a ready-made Tomcat version with a button and verify whether the problem exists before custom changes.
- You can switch Java versions to test compatibility issues.
- You can restart the service cleanly from the panel rather than relying on manual process control.
- You can review deployment-related behavior without needing full server administration access.
This setup is especially useful when troubleshooting JSP, servlet, and WAR deployments that need a private JVM but do not require a large enterprise cluster or complex application server management.
Practical examples of log-based diagnosis
Example 1: Tomcat starts, but the application fails
The Tomcat startup log shows that the server initialized correctly. A few lines later, the application log contains a database connection error caused by an incorrect password. In this case, the fix is not in Tomcat itself. You need to correct the application configuration and redeploy.
Example 2: Service fails immediately after start
The service control log shows a failed start, and the Tomcat log contains a BindException. This suggests a port conflict. A restart after clearing the existing process or adjusting the connector port should solve it.
Example 3: Deployment stops on class loading
The log shows NoClassDefFoundError during startup. The application was compiled with a dependency that is not included in the WAR. The fix is to package the missing library or adjust the build configuration.
Example 4: Works locally, fails on the hosting platform
The log shows an unsupported class version error. The application was built for a newer Java release than the selected hosting runtime. Choosing a compatible Java version or rebuilding the app resolves the issue.
Best practices for reading Tomcat logs in hosting environments
To make future troubleshooting faster, keep a few habits in mind:
- Always save a copy of the failing log segment before making changes.
- Keep deployment timestamps so you can match them to log entries.
- Use clear versioning for WAR files and application packages.
- Monitor both the server log and the application log after each deploy.
- Do not assume the last error line is the root cause.
- Review logs after restarts, not only after full outages.
These habits are especially valuable in managed hosting, where you may not have direct shell access to every system component and need to rely on the control panel and log output to diagnose problems accurately.
When to contact support
Some startup problems can be solved by checking logs and updating the application, but others may need support assistance. Contact support if the logs suggest a platform-level issue that you cannot change from the control panel.
- The service fails before any application log is created.
- The same startup error returns after confirming the Java version and deployment package.
- You suspect a permission issue that you cannot correct yourself.
- The logs point to a limit, service restriction, or panel-side configuration problem.
- The application requires a feature that is outside the standard private JVM / Tomcat setup.
When you contact support, include the exact error message, the time of the failed start, the Java version in use, and any recent changes you made. This helps shorten the investigation.
FAQ
Which log should I check first for a Tomcat startup failure?
Start with the Tomcat startup log, then check the application log. If the service still does not start, review the control panel service log and Apache error log if your app is behind Apache.
Why does Tomcat fail to start without a clear error on the screen?
The control panel may show only a generic failure, while the real cause is written to the logs. Common reasons include port conflicts, Java version mismatch, missing files, or application initialization errors.
How do I know if the problem is in Tomcat or in my application?
If Tomcat itself does not initialize, the issue is likely server-level. If Tomcat starts but the webapp fails during deployment, the problem is usually inside the application package or its configuration.
Can a bad WAR file stop Tomcat from starting?
Yes. A broken WAR, missing dependency, or invalid application descriptor can prevent a webapp from deploying correctly and make the service appear broken during startup.
What if the logs mention a Java version problem?
Check the Java version configured for your app server and compare it to the version required by your application. If needed, switch to a compatible Java runtime or rebuild the app for the selected version.
Should I edit logs to fix the issue?
No. Logs are for diagnosis, not repair. Use them to identify the cause, then fix the application, configuration, or service settings and restart the server.
Conclusion
Logs are the most reliable way to troubleshoot a Tomcat startup problem in a hosting environment. By checking the startup log, application log, service control log, and Apache error log in the right order, you can quickly identify whether the failure comes from Java compatibility, deployment files, permissions, ports, or an application exception.
In a Plesk-based Java hosting setup with My App Server, this process is practical and efficient because you can manage the Tomcat service, select a Java version, deploy applications, and verify the result from one control panel. For JSP, servlet, WAR, and private JVM deployments, that combination usually provides enough visibility to isolate startup issues and resolve them with minimal downtime.