When a Java web app starts returning errors, the fastest way to understand what happened is usually to read the Tomcat logs in the right order and in the right place. On a hosted Tomcat setup, especially when you manage the service through Plesk and a custom Java hosting extension such as My App Server, the logs often tell you whether the issue is a failed deploy, a Java version mismatch, a missing library, a port conflict, a timeout, or simply an application exception that needs code changes.
For UK hosting customers, the process is the same as anywhere else: focus on the error time, check the server-side logs first, and then compare the message with the behaviour in your browser or API client. If your Tomcat app is hosted in a shared hosting account with a private JVM, the logs are usually the most reliable way to diagnose problems without needing root access or a full server team.
What Tomcat logs can tell you
Tomcat application logs record what the container and your Java application were doing when the problem appeared. In a managed hosting environment, this is often enough to identify the root cause quickly, especially if the application is deployed as a WAR file, runs as a servlet/JSP app, or uses a private JVM managed from the control panel.
Typical things you can learn from logs include:
- Whether Tomcat started correctly
- Whether the application deployed successfully
- Which Java version was used
- Whether a class, file, database connection, or environment value is missing
- Whether the application crashed during startup or only on specific requests
- Whether there was a memory problem, timeout, or port conflict
Tomcat logs are especially useful when the browser only shows a generic 500 error, a blank page, a redirect loop, or a slow response without a clear message.
Where to find Tomcat logs in a hosting control panel
On a typical hosted Java setup, logs are accessible from the hosting control panel or inside the account file system. In a Plesk-based environment with My App Server, the exact layout depends on how the app server was created, but the principle is the same: look for the application server’s runtime logs and the web application logs.
Common log locations
- Tomcat startup and service logs
- Java application logs generated by the app itself
- Access logs for requests to the application
- Error logs related to deployment or runtime exceptions
If your hosting provider exposes logs in Plesk, open the service or application server section and look for a logs link, runtime output, or diagnostics area. If logs are stored in the file manager, use timestamps to locate the newest files first. On managed hosting, you may not have access to every low-level system log, but you normally have enough to investigate common application issues.
What if you cannot see logs immediately?
If the logs are not visible in the control panel, check whether the service is running, whether the application is deployed, and whether the account has permission to read the log path. In some cases, logs are generated only after the first request or after the service restarts. If needed, restart the app server from the control panel and reproduce the problem once so a fresh set of entries is created.
Start with the exact time of the failure
The most effective way to read Tomcat logs is to work backwards from the time the problem occurred. Do not scan from the beginning of the file unless the application has only just been deployed. Instead, note the exact time from the browser error, your own test, or the customer report, then search for matching entries around that timestamp.
Pay attention to:
- HTTP status codes such as 500, 404, 503, or 502
- Stack traces beginning with
ExceptionorCaused by - Deployment messages during startup
- Restart events in the service log
- Repeated warnings immediately before the failure
A common mistake is to focus only on the last line in the log. In practice, the root cause is often a few lines earlier, or even in a previous request that triggered a later failure.
How to read a Tomcat stack trace
When a Java application fails, Tomcat often writes a stack trace. This is one of the most useful parts of the log because it shows the exact exception and the path the code took before failing.
What to look for first
- The first exception type
- The message text after the exception name
- The first line in your application package, not just Tomcat internals
- The final
Caused byline, if there are multiple nested exceptions
For example, if you see java.lang.NullPointerException, that indicates the application tried to use a value that was not available. If you see ClassNotFoundException or NoClassDefFoundError, the application is missing a dependency or cannot load a class from the deployed files. If you see SQLException, the problem may be related to the database, credentials, network access, or a schema issue.
How to separate Tomcat messages from application messages
Tomcat itself reports lifecycle, deployment, connector, and service messages. Your application usually writes its own logs through a logging framework such as Logback, Log4j, or JUL. Both are important. A startup failure might appear first in the Tomcat log and then in the application log, or vice versa.
As a rule:
- Tomcat messages tell you about the container and deployment process
- Application messages tell you about business logic and runtime exceptions
When troubleshooting, read both together if possible.
Typical Tomcat log patterns and what they mean
Many hosting issues repeat the same patterns. Recognising them saves time and helps you decide whether the issue is in your app, in the deployed package, or in the hosting configuration.
Application failed to start
If the service starts but the web app does not, look for messages about deployment errors, missing classes, invalid XML, or port binding failures. In a hosted Tomcat setup, this often happens after uploading a new WAR file or changing configuration.
Common causes include:
- Broken deployment package
- Incorrect web.xml or context configuration
- Missing JAR files
- Wrong Java version selected for the app
- Application-specific startup exceptions
HTTP 500 errors
A 500 error usually means the application ran into an unhandled exception. The log should show the exact reason. Search around the request time and identify the first error line. If the same request fails every time, reproduce it once and compare the entries before and after the failure.
Application starts but pages are blank
This often points to a view-layer error, a template problem, or a runtime exception that is being handled poorly by the application. Check whether the browser request appears in the access log and whether the application log shows an exception at the same time.
Timeouts and slow responses
If the site is slow rather than broken, logs may show database delays, repeated retries, GC pressure, or upstream service timeouts. In hosted Java environments, the issue may also be related to resource limits, especially if the application is approaching the memory or CPU allowances of the account.
Restart loops
If Tomcat keeps restarting, the log may show a startup exception, a crash, or repeated service failures. Read the first failure carefully. Restart loops usually hide an initial root cause such as an invalid configuration file, an incompatible library, or an application that exits during startup.
Practical steps to diagnose a problem in Tomcat logs
Use this workflow when you need to identify what went wrong on a hosted Tomcat app:
- Reproduce the problem once, if safe to do so.
- Note the exact time and the affected URL.
- Open the Tomcat service log and the application log.
- Search for
ERROR,Exception,SEVERE, andCaused by. - Check the lines immediately before the error, not just the error itself.
- Compare the error with recent changes such as a new WAR upload, config update, or Java version switch.
- Restart the service only after you have saved the log evidence.
If the issue happened after a deploy, compare the timestamp with the deployment time. In many cases, the log shows the exact moment Tomcat unpacked the application and where the process stopped.
How My App Server helps with Tomcat log troubleshooting
In an ITA managed hosting environment, My App Server provides a practical way to run a private Tomcat or private JVM inside a shared hosting account. That is useful because you can manage the service, select a Java version, deploy your app, and review runtime behaviour without depending on a complex external platform.
This setup is particularly helpful for:
- Java hosting for small and medium applications
- Tomcat hosting for WAR deployments
- JSP hosting and servlet hosting
- Private JVM hosting with account-level control
- Fast testing of different Java versions
Because the app server is controlled through Plesk, troubleshooting is usually more straightforward than on a manually managed server. You can restart the service, confirm the selected runtime, and review the logs from the same place. That reduces the time spent guessing whether the problem is in the application, the container, or the configuration.
How to distinguish application bugs from hosting configuration issues
Not every error is caused by code. Logs help you determine whether the issue belongs to the application or to the hosting configuration.
More likely an application bug
- Null pointer exceptions
- Validation or parsing errors
- Missing business data
- Database query failures caused by app logic
- Errors that happen only on one specific page or action
More likely a hosting or runtime configuration issue
- Application does not start after a Java version change
- Deployment fails because of missing permissions
- Tomcat cannot bind to the required service port
- Runtime resources are exhausted
- Logs show a failure before the application code is even loaded
When you are unsure, compare the same app on a previous working deployment, if available. A change in logs after a Java upgrade or redeploy often shows whether the breakage is environment-related.
Reading access logs alongside error logs
Access logs and error logs serve different purposes, but together they give a clearer picture. Access logs show the request path, status code, client IP, and timestamp. Error logs show what went wrong during processing.
Use access logs to answer:
- Was the request received?
- Which URL or API endpoint failed?
- Did the response return 500, 404, or 302?
- Did the same user repeat the request?
Use error logs to answer:
- Why did the request fail?
- Which class or method threw the exception?
- Was the database or another service involved?
- Did Tomcat report a container-level problem?
If the access log shows no request at all, the issue may be outside the application, such as DNS, proxy, or browser caching. If the request appears in access logs but no application log is written, the app may have crashed before the logger could write output.
Best practices for working with Tomcat logs on managed hosting
Good log handling makes troubleshooting easier and reduces the risk of missing the real error.
- Keep logs rotated so old errors do not hide new ones
- Use clear timestamps in a consistent time zone
- Record what changed before the problem appeared
- Do not delete logs before capturing the error details
- Compare startup logs after each deployment
- Keep application logging at a useful level, not too quiet and not overly verbose
If you maintain several hosted Java apps, it is worth standardising your deploy process so you can quickly compare log patterns across environments. Even on shared hosting, consistent deployment names and log locations make support work much faster.
Common questions about Tomcat logs
Why does Tomcat show an error after I upload a new WAR file?
Most often the application failed during deployment or startup. Check the log for missing classes, invalid configuration, Java compatibility issues, or permission problems. If the WAR works in one Java version but not another, the selected runtime may need to be changed.
Can I diagnose a 500 error from the logs alone?
Often yes. A 500 error is usually paired with a stack trace or application exception in the log. If the log is empty, check whether the request reached the server, whether the service is running, and whether logging is enabled for the application.
What is the difference between Tomcat log and application log?
Tomcat logs are produced by the container and service. Application logs are produced by your Java code. In practice, you should read both because one may contain the deployment failure and the other may contain the business logic exception.
What should I check first after a restart failure?
Check the first error after the restart begins, not the final line. The earliest exception usually explains why Tomcat could not continue. If the service repeatedly fails, the same root cause is often repeated in every restart attempt.
Do I need root access to read Tomcat logs?
No, not usually in a hosted Java environment. In a Plesk-managed setup with My App Server, the relevant service and application logs are typically available from the account or control panel level, which is enough for day-to-day troubleshooting.
Checklist before contacting support
If you still cannot find the cause, collect the following information before opening a support request:
- Exact time the error occurred
- Requested URL or application path
- Screenshot of the browser error, if applicable
- Relevant log excerpt with timestamps
- Any recent changes to the WAR, configuration, or Java version
- Whether the issue happens for one user or all users
This helps support teams identify whether the issue is in the application code, the Tomcat service, or the hosted environment much faster.
Conclusion
Reading Tomcat application logs is one of the most reliable ways to diagnose problems in a hosted Java environment. Start with the failure time, compare access logs and error logs, and look for the first meaningful exception rather than the last line only. In a Plesk-based hosting platform with My App Server, this approach is especially practical because you can control the Tomcat service, select the Java version, and review the runtime behaviour from the same account.
For Java hosting, Tomcat hosting, JSP hosting, or servlet hosting, the logs are often the difference between guessing and knowing. Once you learn to identify startup failures, stack traces, and deployment errors, troubleshooting becomes much faster and much more predictable.