If a hosted Tomcat application suddenly stops responding, the fastest way to find the cause is usually in the logs. In a managed hosting environment, Tomcat failures are often visible long before they become permanent: a bad deploy, a missing class, a failed database connection, an out-of-memory condition, or a startup error after a Java version change. When you use a control panel such as Plesk with a Java hosting solution like My App Server, the first place to check is always the application and service log output, followed by the service status and the last deployment changes.
For most Tomcat hosting and JSP hosting issues, the question is not whether the logs contain the answer, but which log to look at first. This guide shows the practical order of checks for a hosted Apache Tomcat app, how to read the most useful log messages, and what to do next inside a hosting control panel.
Check the application logs first
When a Tomcat app stops working, start with the application logs generated by the JVM and the web application itself. In a Plesk-based Java hosting setup, these logs are usually the fastest way to identify whether the problem is in your code, your deployment package, the runtime, or a service-level issue.
Look for:
- Startup failures after a deploy or restart
- Stack traces with
Exception,Error, orCaused by - Database connection errors such as timeouts or authentication failures
- Class loading problems like
ClassNotFoundExceptionorNoClassDefFoundError - Memory-related failures including
OutOfMemoryError - Port or bind issues if the server cannot start a service
In practice, you want the lines around the timestamp when the app stopped working. The error is often not the first line you see; the real cause is usually a few lines earlier, after a nested Caused by chain.
What a useful log entry looks like
Examples of messages that deserve attention:
SEVERE: Error deploying web application archivejava.lang.ClassNotFoundExceptionjava.sql.SQLTransientConnectionExceptionjava.lang.IllegalStateExceptionOutOfMemoryError: Java heap space
If your application was working before and stopped right after a deploy, the application log is the best starting point. If it stopped after a restart or configuration change, check the service log next.
Confirm whether Tomcat is actually running
A hosted Tomcat application can appear “down” for two very different reasons: the application failed inside Tomcat, or the Tomcat service itself is not running. Before spending time in the code, confirm the service state in the hosting panel.
In a managed hosting environment with My App Server, the control panel usually provides service control actions such as:
- Start
- Stop
- Restart
- View service status
If the service is stopped, unavailable, or restarting repeatedly, the problem may be with the JVM startup, the Tomcat configuration, or a resource limit. If the service is running but the app is failing, focus on the webapp logs, Catalina logs, and deployment output.
Why service status matters
Tomcat may be online while your application is not. For example, one WAR file can fail to deploy while the rest of the container remains healthy. In that case, the service control panel might show the JVM as running, but the application log will contain deployment errors. This distinction helps you avoid restarting the entire service when the real issue is only one app package.
Look at the most recent deployment changes
If the app stopped working after a file upload, version upgrade, or configuration edit, check what changed last. In hosted Tomcat environments, many failures are caused by a recent deploy rather than a spontaneous outage.
Review:
- The most recent WAR upload
- Changes to
web.xml - Changes to context configuration
- New library files added to
WEB-INF/lib - Changes to Java version or Tomcat version selection
- Any manual edits to JVM parameters or application server settings
A new library can break class loading. A configuration file with a syntax error can prevent startup. A Java version mismatch can expose code that worked before but is no longer compatible. If you are using My App Server to manage a private JVM and Tomcat instance in your hosting account, changes to runtime version and application packaging are especially important to review.
Use the log timestamps to narrow down the failure window
Logs become much easier to read when you anchor them to a precise time. Start by identifying when the application last worked, then compare that to the last successful request or the last restart.
Useful questions:
- Did the problem start after a specific request?
- Did it begin after a scheduled or manual restart?
- Did the app fail right after deployment?
- Did the issue start after changing the Java version?
- Did all pages fail, or only one function?
If the application was responding slowly before it stopped, look for warnings leading up to the outage. For example, repeated database timeout messages may appear long before the final failure. In Tomcat hosting, these warning signs are often the first clue that the JVM or an external service is under pressure.
Read the error chain, not only the top line
Java logs often include a stack trace with multiple nested causes. The first line may say the app failed to start, but the root cause may be several lines deeper. Always scan for:
Caused by:Root causeSuppressedat ...lines near the first error
Example patterns you may see:
- A controller error caused by a missing configuration property
- A servlet initialization failure caused by a missing JDBC driver
- A startup failure caused by incorrect file permissions
- A connection refusal caused by the database service not being reachable
In hosted Java environments, the visible message is not always the true problem. A log line about “failed to initialize application context” may be the result of a single missing environment value. Reading the chain helps you avoid guessing.
Check for common Tomcat startup and runtime problems
Some log patterns appear repeatedly in hosted Tomcat support cases. If your app stopped working, compare your logs to these common categories.
Class loading and missing dependency errors
If the app logs show ClassNotFoundException or NoClassDefFoundError, Tomcat cannot find a required class. This is often caused by:
- Missing JAR files in the deployment package
- Conflicting library versions
- Using a framework dependency that is not bundled correctly
- Removing a file during a partial upload
In a shared hosting Java setup, these issues are usually fixed by correcting the WAR content and redeploying it cleanly.
Database connection failures
If your app depends on a database, check for SQLException, connection timeout messages, or authentication errors. Common causes include:
- Wrong username or password
- Changed database host or port
- Connection pool exhaustion
- Database service outage
- SSL or certificate mismatch
When the database is down, some applications fail during startup, while others load partially and fail only when a page tries to query data.
Memory pressure and JVM exhaustion
OutOfMemoryError is a strong signal that the JVM has run out of heap or is under heavy memory pressure. In hosted Tomcat environments, this can happen when:
- The app loads too much data into memory
- A leak keeps objects from being released
- The heap setting is too low for the workload
- Traffic increased without a corresponding runtime adjustment
If your hosting plan uses a private JVM through My App Server, review the JVM memory settings in the control panel and compare them with your app’s actual usage. Do not increase memory blindly; first confirm whether the app has a genuine leak or an unusually heavy request pattern.
Permission and file access problems
Hosted applications often fail because Tomcat cannot read a file, write a temp directory, or access an uploaded resource. Log messages may mention:
Permission deniedFile not foundCannot create directoryRead-only file system
Check whether the app is trying to write outside its allowed paths. In managed hosting, the filesystem layout matters, and applications should only write to locations designed for runtime data, uploads, or temporary files.
Check Tomcat service logs and restart history
If the application log does not explain the outage, move to the Tomcat service logs. These logs show whether the container started correctly, whether the JVM launched with the expected Java version, and whether Tomcat encountered errors during service startup or shutdown.
Look for:
- JVM startup command lines
- Selected Java version
- Tomcat initialization messages
- Port binding problems
- Shutdown or crash messages
- Repeated restart attempts
In a control panel environment, a recurring restart loop often points to a configuration issue rather than a temporary outage. If Tomcat starts and immediately exits, the service log may contain the first clear sign of the failure.
What repeated restarts usually mean
Repeated restarts are often caused by one of these:
- A syntax error in configuration
- An incompatible Java runtime
- Port conflict or bind failure
- Memory limits being hit at startup
- A webapp crash that triggers a service recovery loop
If you use My App Server, check whether the selected Tomcat version and Java version still match your application requirements. A version change can sometimes surface old code assumptions that were previously hidden.
Use the control panel to verify Java version and runtime settings
When a hosted Tomcat app breaks after a change, the runtime version is one of the first things to verify. A Java application may fail because it was compiled for a newer or older runtime than the one currently selected.
Check:
- Current Java version
- Tomcat version
- Any custom JVM arguments
- Heap or memory settings
- Application server startup configuration
In a Plesk-based Java hosting setup, these settings are often easier to manage than on a manually configured server, but they still need to match the app’s requirements. If the application was running on one Java version and stopped after switching to another, the logs may show deprecated API usage, module issues, or startup incompatibility.
Inspect access logs only after the application logs
Access logs are useful, but they are secondary when an app stops working. They tell you what requests reached the server and which returned errors, but they do not usually explain the root cause.
Use access logs to answer:
- Is the browser reaching Tomcat at all?
- Are responses returning 500, 503, or 404?
- Did the failure begin at a specific request path?
- Are there repeated requests causing load or errors?
If you see many 500 Internal Server Error responses, the application log for the same timestamp should show the underlying exception. If you see 404 on all paths, the deploy may be incomplete or the context path may be wrong.
Practical troubleshooting order for a hosted Tomcat app
When the app stops working, use this order to save time:
- Check whether the Tomcat service is running.
- Open the application log around the failure timestamp.
- Read the full stack trace, including
Caused bylines. - Review the latest deployment and configuration changes.
- Verify Java version, Tomcat version, and JVM settings in the control panel.
- Check service logs for startup failures or restart loops.
- Use access logs to confirm request patterns and response codes.
This sequence works well for small and medium Java applications hosted on a shared platform with private JVM control. It helps you separate code issues from runtime issues and avoids unnecessary restarts.
What to collect before contacting support
If you need help from hosting support, send the right details the first time. That speeds up diagnosis and reduces back-and-forth.
Include:
- The exact time the issue started
- The application or context path affected
- The latest log lines around the failure
- Any recent changes to WAR files or configuration
- The selected Java version and Tomcat version
- Whether the service is running, stopped, or restarting
- Any error message shown in the browser
If the issue began after a deploy, mention what changed in the package. If it began after a version switch in My App Server, note the previous and current Java versions. This helps support focus on the right layer immediately.
FAQ
Where should I look first when my hosted Tomcat app stops working?
Start with the application logs for the exact time the problem began. If the service itself is not running, check the Tomcat service status and service logs next.
Why does Tomcat run but my app still fails?
Tomcat can be healthy while one web application fails to deploy or crashes at runtime. In that case, the issue is usually inside the app package, its dependencies, or its configuration.
What is the most common log message for a broken Tomcat app?
Common messages include ClassNotFoundException, NoClassDefFoundError, SQLException, and OutOfMemoryError. The exact message depends on whether the failure is related to code, database access, memory, or runtime configuration.
Should I restart Tomcat before reading the logs?
No. Read the logs first if possible. Restarting without checking the error can hide the original cause or overwrite helpful startup details.
How do Java version changes affect a hosted Tomcat application?
If the application was built for a different Java version, it may stop starting or fail at runtime after a version change. Always compare the app requirements with the Java version selected in the control panel.
What if the log file is too large?
Filter by timestamp, search for Error and Exception, and focus on the period when the app stopped responding. The useful line is often near the first severe error, not at the very end of the file.
Conclusion
When a hosted Tomcat app stops working, the fastest path to a fix is to begin with the application logs, then verify Tomcat service status, deployment changes, and Java runtime settings. In a managed Java hosting environment with Plesk and My App Server, this approach is especially effective because you can quickly check the container, the JVM, and the deploy from one place. Most outages are explainable through a clear log message, a recent change, or a mismatched runtime setting.
By reading the logs in the right order, you can identify whether the problem is in the application, the Tomcat service, or the hosting configuration, and take the next step with confidence.