If your Tomcat application suddenly stops working, shows a 404 or 500 error, or loads only a blank page, the fastest way to find the cause is to check the error path in a structured order: application logs, Tomcat service status, deployment files, Java compatibility, and web server routing. In a managed hosting setup with Plesk and a private Java environment such as My App Server, most broken app issues are usually caused by a deployment mismatch, a missing file, a startup failure, or an incorrect context path rather than a problem with the hosting platform itself.
This guide explains how to troubleshoot a broken Tomcat application on a hosting account, how to distinguish between 404, 500, and startup errors, and which checks are most useful when you manage your Java app through a control panel.
Check the exact symptom first
The first step is to identify what kind of failure you are seeing, because the cause is often different for each case.
- 404 Not Found usually means the application is not deployed where the web server expects it, the context path is wrong, or the app failed to start and is therefore not available.
- 500 Internal Server Error usually means the app started but crashed during a request, or Tomcat encountered an exception while processing the application.
- Blank page / partial page often points to frontend resource problems, failed JSP compilation, JavaScript errors, or missing backend data.
- Connection refused / gateway error often means Tomcat is down, the JVM is not running, or the proxy/web server cannot reach the app service.
When troubleshooting, note the exact URL, the time of the failure, and whether the issue affects one page, one application, or everything in the account. That information makes log review much faster.
Confirm whether the Tomcat service is running
In a hosting platform with a private JVM or private Tomcat instance, the service status is one of the first things to verify. If the service is stopped, the app cannot answer requests at all, which can look like a 404 or a gateway error depending on the routing setup.
What to check in Plesk or the hosting control panel
- Open the Java or app server management area.
- Check whether the Tomcat service is running, stopped, or starting repeatedly.
- Review the last start time and any recent service actions.
- If available, inspect the service control output for errors.
If the app server does not start, the cause is often visible in the startup log. Common reasons include an invalid Java version, bad configuration in server.xml or context files, missing permissions, port conflicts, or a broken WAR archive.
Review the application and Tomcat logs
Logs are usually the most reliable source for finding the cause of a broken Tomcat application. When an app fails, Tomcat almost always leaves a trace in the catalina or application logs.
Most useful log files
- Tomcat startup log for service boot errors, port issues, or JVM problems.
- Catalina log for deployment problems and runtime exceptions.
- Application-specific log if the app writes one.
- Web server error log if Apache or a proxy is forwarding traffic to Tomcat.
Look for messages such as:
SEVEREerrors during deploymentClassNotFoundExceptionorNoClassDefFoundErrorUnsupportedClassVersionErrorOutOfMemoryErrorPort already in useFailed to initializeContext ... failed to start
These messages usually point directly to the cause. For example, a Java version mismatch can break startup after a deployment, while a missing library often causes a 500 error only when a specific feature is used.
Verify the deployment path and context mapping
A very common reason for a broken Tomcat application is that the application is deployed, but not under the URL you expect. This can create a 404 even when the app is technically running.
Typical causes of a 404 in Tomcat hosting
- The WAR file was uploaded to the wrong directory.
- The application context path does not match the requested URL.
- The app was deployed as
/appnamebut the browser is calling/. - The app was removed or renamed, but the old URL is still being used.
- The deployment failed silently and no active context exists.
Check the following:
- Is the WAR file present in the correct deploy folder?
- Has Tomcat unpacked the application successfully?
- Does the context name match the route used by the browser?
- Is there a custom context file redirecting the app to another path?
If your hosting control panel supports custom application servers, make sure the selected Tomcat instance is the same one used by the website or domain. In multi-app setups, a URL can point to the wrong app server instance if the mapping was changed recently.
Check Java version compatibility
Broken Tomcat applications often fail because the app was compiled for a different Java version than the one currently selected in the hosting account. This is especially important when you can choose from several Java/Tomcat versions in the control panel.
Common compatibility problems
- The app was built for a newer JVM than the one in use.
- A library requires a specific Java release.
- The app runs on one Java version but fails after switching to another.
- The deployment works locally but not on the hosted environment.
A typical error looks like this:
UnsupportedClassVersionError— the bytecode was compiled with a newer Java version.NoSuchMethodError— a dependency version changed or is missing.ClassNotFoundException— a required library is not in the classpath.
If you are using a platform that lets you switch Java versions for the private JVM, confirm that the selected version matches your application requirements. If the app worked before and then stopped after a runtime change, revert to the previous compatible version and test again.
Inspect the WAR, libraries, and application files
A broken app can also be caused by a bad deployment package. If the WAR file is incomplete, corrupted, or missing dependencies, Tomcat may deploy it partially and then fail at runtime.
What to look for in the deployment package
- Missing
WEB-INFfolder content - Missing JAR files in
WEB-INF/lib - Wrong file permissions after upload
- Corrupted archive created by a failed build
- Configuration files with invalid values
For JSP and servlet applications, also check:
- JSP syntax errors
- Servlet mapping errors in
web.xml - Incorrect resource references
- Missing external configuration files
If the application uses environment-specific settings, confirm that the production values are present on the hosting account. A missing database URL, API key, or file path can break the application during startup or on the first request.
Check database access and external dependencies
Many Tomcat applications are not broken because of Tomcat itself, but because they cannot connect to a required service. If the app depends on a database, cache, file share, or external API, a connection issue can produce 500 errors or prevent the app from loading.
Common dependency-related causes
- Wrong database hostname, username, or password
- Database service unavailable
- Firewall or network block to an external API
- Expired certificate for a secure endpoint
- Missing driver library for the database type
Signs that dependencies are the problem include:
- The homepage loads, but login or search fails.
- The app works for one function but not another.
- Errors appear only after data access.
- The app logs contain connection timeout or authentication errors.
If your application was recently moved, updated, or redeployed, verify that all environment variables and datasource settings are still correct.
Look for port conflicts and proxy routing issues
In managed hosting environments, Tomcat may run behind Apache or another web server. That means the public URL may not point directly to Tomcat, and routing problems can appear as broken app errors.
What can go wrong
- Apache routes traffic to the wrong internal port.
- The Tomcat service is listening on a port that is already in use.
- A reverse proxy rule points to an old app instance.
- The domain is mapped to the wrong virtual host.
- The application context changed but the proxy configuration was not updated.
These issues are often visible in the web server error log and the Tomcat startup log. If Tomcat starts but the browser still shows an error, a proxy mapping or virtual host configuration is a strong suspect.
Test whether the problem is global or page-specific
Not every 500 error means the whole application is broken. Sometimes only one endpoint, JSP page, or action fails.
Useful test steps
- Open the home page and a few internal URLs.
- Try a static resource such as a CSS or image file.
- Try a page that does not require login.
- Compare the failing route with a working route.
- Test from another browser or incognito mode to rule out cache issues.
If only one page fails, the problem is likely in that page’s controller, template, database query, or JSP logic. If every page fails, focus on deployment, startup, or routing.
Check recent changes before assuming the hosting platform is at fault
Most broken Tomcat applications start failing after a change. The most useful question is often: what changed just before the issue began?
Common change triggers
- New WAR deployment
- Java version switch
- Updated dependencies
- Changed context path
- Modified web.xml or server configuration
- New environment variable or secret
- File permission changes
If the app worked yesterday and failed after deployment today, compare the current package with the previous known-good version. In many cases, rolling back the last build is the fastest way to restore service while you investigate the exact cause.
Use a simple isolation checklist
If you need a fast method to narrow down the issue, work through this checklist in order:
- Confirm the exact error: 404, 500, blank page, or startup failure.
- Check whether the Tomcat service is running.
- Review the startup and application logs for SEVERE errors.
- Verify the WAR file and deployment folder.
- Confirm the context path and URL mapping.
- Check the Java version selected for the app server.
- Review database and external service connectivity.
- Inspect recent application or configuration changes.
- Test whether the issue affects one page or the entire app.
This order helps separate routing problems from application failures and reduces time spent chasing the wrong layer.
How My App Server helps with Tomcat troubleshooting
When you manage Java hosting through a Plesk-based solution such as My App Server, troubleshooting is usually easier because you can control the app server, Java version, and service state from one place. That is useful for shared hosting accounts that need a private JVM for a small or medium Java application.
Practical advantages during troubleshooting
- You can check whether the private Tomcat service is running.
- You can switch or verify the Java version if the app is version-sensitive.
- You can review logs and service output in the control panel.
- You can deploy WAR-based applications and restart the service after changes.
- You can isolate one app server from other sites or app deployments on the account.
This setup is well suited to JSP, servlet, and WAR deployments where you need direct control without managing a full enterprise application platform. If the app is larger than the standard hosting model is designed for, the same logs and checks still help determine whether the issue is application-related or environment-related.
When to contact support
You should contact hosting support if you have already checked the logs, confirmed the service status, and the issue still looks like a platform or routing problem.
Useful details to include:
- The exact URL that fails
- The time the problem started
- The error code or browser message
- The last successful deployment or change
- Relevant log excerpts
- The Java version currently selected
- Whether the app server starts successfully
Providing this information usually shortens the investigation and helps distinguish a broken app from a service-level issue.
FAQ
Why does Tomcat show 404 when the app is deployed?
Usually because the context path does not match the URL, the deployment failed, or the app is mapped to a different location than expected. Check the deploy folder and the active context in the control panel.
Why does my Tomcat app return 500 after a restart?
A restart can expose configuration problems, missing files, incompatible Java versions, or database connection failures. Review the startup log and application log for the first error after boot.
What is the most common cause of a broken Tomcat app on hosting?
The most common causes are deployment errors, Java version mismatch, missing dependencies, and wrong context mapping. These are more common than a core Tomcat failure.
How do I know if the problem is in Apache or Tomcat?
If the site shows a proxy or gateway error, check Apache or routing first. If the app starts but throws exceptions inside the page, the issue is more likely in Tomcat or the application code.
Can a WAR file deploy but still be broken?
Yes. Tomcat may unpack the WAR successfully while the application still fails at runtime because of a missing library, invalid configuration, or database connection problem.
Should I rebuild the app or change the Java version first?
If the logs show a Java compatibility error, adjust the Java version first. If there is no clear version mismatch, compare the current deployment with the last known-good build and check dependencies and configuration.
Summary
To find the cause of a broken Tomcat application, start with the visible error, then check service status, logs, deployment location, Java compatibility, and external dependencies. In a Plesk-based hosting environment with a private Tomcat or JVM, most issues can be narrowed down quickly by reviewing the startup output and application logs. A 404 usually points to routing or context mapping, while a 500 usually points to an application exception, configuration problem, or dependency failure.
When you follow a step-by-step approach, it becomes much easier to identify whether the problem is in the WAR package, the Java runtime, the proxy setup, or the application itself.