If a hosted Tomcat application suddenly stops working, the fastest way to find the cause is to start with the application logs, then check the Tomcat service status, the Java version in use, and any recent deployment changes. In a managed hosting environment, most Tomcat issues are visible very early in the log files, especially when the app fails to start, a WAR file deploys incorrectly, or the JVM runs into a configuration problem.
In a UK hosting context, the same troubleshooting approach applies whether you are using a shared hosting account with a private JVM or managing your Java app through a control panel such as Plesk. If your hosting platform includes a Tomcat extension such as My App Server, you can usually diagnose most problems without needing shell access or enterprise tooling.
Check the application log files first
The first place to look is the application log, not the browser error page. A Tomcat app can fail for several reasons, but the log usually tells you whether the problem is caused by code, configuration, deployment, or the runtime environment.
Look for:
- Startup errors after a restart or redeploy
- Exceptions when the app receives a request
- Database connection failures
- Missing files, classes, or libraries
- Permission errors when reading or writing data
- Memory-related messages such as out-of-memory conditions
If you are using My App Server in Plesk, check both the Tomcat service log and the application-specific logs created by your app. Many Tomcat deployments also write to standard output and standard error streams, which can contain the earliest sign of a problem.
What to search for in the log
When an app stops working, search the log for the following patterns:
- Exception and Caused by lines
- SEVERE, ERROR, or FATAL
- Deployment failed or failed to start
- Context initialization failed
- ClassNotFoundException or NoClassDefFoundError
- NullPointerException if the failure happens after login or on a specific page
Pay attention to the first error in the chain. Later messages are often consequences of the real problem.
Confirm whether Tomcat is running
If the log is not immediately clear, check the Tomcat service itself. A hosted Java app can stop working because Tomcat is not running, is restarting repeatedly, or started with the wrong Java runtime.
In a control panel environment, service control is usually the next step after reading the logs. If your platform provides a service control page, verify:
- The Tomcat service is started
- The service did not crash after startup
- The correct Java version is selected
- The deployment path still points to the expected application
If the service starts and then stops right away, the problem is often visible in the startup log. Common causes include invalid XML configuration, a broken WAR file, incompatible libraries, or a runtime mismatch.
Typical signs of service failure
- Application returns 502 or 503 errors
- The app worked after deployment but fails after restart
- Tomcat appears active in the control panel, but the site is not responding
- Only one application path fails, while the rest of the account is reachable
In a managed hosting setup, these symptoms often mean the JVM or web application layer is affected, not the entire hosting account.
Check the deployment status and the WAR file
For Tomcat hosting, deployment problems are among the most common causes of an application suddenly stopping. If you deployed a new WAR file shortly before the issue started, verify that the upload completed correctly and that the app expanded without errors.
Review:
- Whether the WAR file name is correct
- Whether the deployment folder was updated
- Whether the application unpacked successfully
- Whether a previous version is still partially present
A partially uploaded or corrupted WAR file can cause startup failures, missing pages, or repeated restarts. If your app uses JSP files, also confirm that the compiled classes and generated cache files are not stale or broken.
Deployment issues that often appear in logs
- Archive cannot be read or expanded
- Duplicate application context
- Missing web.xml or invalid web.xml structure
- XML parsing errors in context files
- Dependency conflicts after a library update
If the app worked before a redeploy, compare the current package with the previous working version. In many cases, the fastest fix is to roll back to the last known good WAR file and recheck the logs.
Review the Java version and JVM settings
A hosted Tomcat app may fail because it was built for one Java version but is running on another. This is especially important when your hosting platform lets you choose between several Java versions or install a custom runtime.
Look for signs of version mismatch such as:
- Unsupported class version errors
- Libraries that require a newer JVM
- Code compiled with a different target release
- Warnings after a Java upgrade
If your platform supports a private JVM, confirm that the selected Java version matches the application requirements. Even a minor mismatch can break startup or specific features.
Also check JVM memory limits
Applications can stop working because the JVM runs out of memory or because heap settings are too low for the current workload. Log entries may mention:
- OutOfMemoryError
- Java heap space
- GC overhead limit exceeded
- Unable to create new native thread
If this happens repeatedly, the app may need a smaller cache, fewer background tasks, or adjusted memory settings within the limits of the hosting plan.
Inspect recent changes in the application
When a Tomcat app stops working, the change most recently made is often the real cause. Before changing settings, ask what changed just before the failure:
- New WAR upload
- Database schema update
- Modified configuration file
- New third-party library
- Changed environment variable
- Updated login or session handling code
Even when the hosting platform is healthy, a small application change can break startup or make only one section of the site fail. If the issue began after a release, use the logs to confirm whether the error occurs during deployment, initialization, or when a specific request is processed.
Useful rollback checks
- Restore the previous WAR file if available
- Compare old and new configuration files
- Check whether new external services are reachable
- Verify that credentials and connection strings are still valid
Look at database and external service errors
Many hosted Java applications depend on a database, API, SMTP service, or other external component. If any of those services become unavailable or credentials change, Tomcat may still start, but the app will stop working for users.
Common log messages include:
- Connection refused
- Access denied
- Timeout while connecting
- Unknown host
- Authentication failed
If the app fails only on certain pages or actions, a database query or external API call may be involved. Check whether the application can load its home page but fails when logging in, submitting forms, or downloading data. That pattern often points to a downstream dependency rather than Tomcat itself.
What to verify
- Database hostname and port
- Database username and password
- JDBC driver compatibility
- Firewall or network restrictions
- API endpoints and certificates
In managed hosting, these issues are usually diagnosed from the app log even if the external service itself is outside the hosting account.
Check file permissions and missing resources
Tomcat applications often stop working because the app can no longer read a file, write a temporary file, or access a directory it depends on. This is common after a deployment, a cleanup task, or a change in the application path.
Look for log messages involving:
- Permission denied
- File not found
- Cannot create directory
- Read-only file system
- Failed to load resource
Also check whether the application expects files in a directory that no longer exists after redeployment. Relative paths are especially risky in hosted Java apps because the working directory may differ from a local test environment.
Use the Tomcat and web server logs together
In some hosting setups, Apache may sit in front of Tomcat. If the browser shows an error, it helps to check both the Apache log and the Tomcat log to see where the request fails.
Use the following rule of thumb:
- Apache errors often point to routing, proxy, or upstream connection problems
- Tomcat logs often point to the application, JVM, or deployment problem
- Application logs often show the exact business logic or dependency failure
If Apache cannot reach Tomcat, the app may appear down even though the application itself has not crashed. If Tomcat is healthy but the app is broken, the issue is usually inside the Java application or its dependencies.
How to read the first useful error in the log
When a log contains multiple errors, do not focus only on the last message. The important line is usually the first real failure in the chain. A later stack trace may be large, but it often starts because one class, file, or service could not be loaded.
A practical way to read the log is:
- Find the time the app stopped working
- Scroll upward to the first severe error
- Identify the root cause line after Caused by
- Check whether the error is deployment, dependency, permission, or runtime related
- Confirm whether the issue is repeatable on every restart
If the same error appears after every restart, the application is likely failing during initialization. If the error only appears for one request, the problem may be in a specific function, controller, or JSP page.
Practical troubleshooting checklist
Use this sequence when a hosted Tomcat app stops working:
- Open the application log and find the first error
- Check whether Tomcat is running in the control panel
- Review recent WAR deployments or file uploads
- Confirm the selected Java version is compatible
- Look for memory or JVM startup errors
- Verify database and external service connectivity
- Check file permissions and missing resources
- Compare the current app version with the last working version
If you are using My App Server, this process is especially useful because you can manage the private JVM and Tomcat instance from the hosting control panel without needing a separate application server platform.
When the issue is likely in the application, not the hosting platform
Many support tickets start with a general report that the app is down, but the logs quickly show a code-level issue. The problem is likely inside the application if you see:
- NullPointerException on a specific page
- Failed SQL query after a form submit
- Missing class from a custom library
- Broken JSP compilation
- Application-specific authentication failure
In those cases, the hosting service may still be functioning correctly. The next step is usually to correct the code, update the package, or restore a known working release.
FAQ
Where should I look first if my hosted Tomcat app is down?
Start with the application log and Tomcat startup log. These usually show whether the app failed to deploy, whether the JVM had a problem, or whether a dependency such as a database is unavailable.
What if the site shows a 503 error?
A 503 often means the backend service is unavailable or the app is not responding. Check whether Tomcat is running, then review the log for startup errors, memory issues, or deployment failures.
Can a wrong Java version stop a Tomcat app from working?
Yes. A Java version mismatch is a common cause of startup failure after deployment or server-side changes. Look for class version errors and confirm that the selected Java runtime matches the application build.
Should I check Apache logs too?
Yes, if Apache is used as a front end or reverse proxy. Apache logs can show request routing issues, while Tomcat and application logs usually reveal the real cause inside the Java stack.
What does it mean if the app worked before but not after a redeploy?
That usually points to a deployment problem, a broken WAR file, an incompatible library, or a changed configuration file. Compare the current version with the last working release and inspect the deployment log.
Do I need shell access to diagnose Tomcat issues?
Not necessarily. In many managed hosting setups, including Plesk-based Java hosting, you can identify the root cause from the logs and service controls available in the panel.
Conclusion
When a hosted Tomcat application stops working, the safest and fastest approach is to begin with the logs, then confirm Tomcat service status, Java version, deployment health, and external dependencies. In most cases, the first useful error in the application or startup log will point you directly to the root cause.
For UK-based hosting customers using a control panel environment such as My App Server, this makes troubleshooting practical and efficient: you can manage a private JVM, select the right Java version, deploy WAR files, and read application logs from one place. If the app still fails after these checks, the next step is usually to roll back the last change or inspect the specific exception shown in the log.