If a Tomcat deployment stops working after an upload, configuration change, or application update, the fastest way to recover is to isolate where the failure starts: the application package, the Tomcat service, the Java version, or the web server proxy in front of it. On managed hosting with Plesk and a Java extension such as My App Server, most broken deployments are caused by a small set of issues: an invalid WAR, a startup exception, a port conflict, a bad context path, missing permissions, or a JVM mismatch.
This guide explains how to troubleshoot a broken deployment on Tomcat hosting in a practical order. It is suitable for shared Java hosting, JSP hosting, servlet hosting, and private JVM setups where you deploy and manage your own Tomcat instance from the control panel.
Check whether the deployment failed or the application failed after startup
The first step is to decide if Tomcat itself is down, or if Tomcat started correctly but your application did not load. These are different problems and require different fixes.
Signs that Tomcat did not start
- The service is stopped in Plesk or in the hosting control panel.
- The app URL returns a connection error, gateway timeout, or empty response.
- Every deployed application on the same Tomcat instance is unavailable.
- Recent log entries mention startup failure, JVM errors, or port binding issues.
Signs that only one deployment is broken
- Tomcat is running, but one WAR does not open.
- Other Java apps on the same service still work.
- The browser shows 404, 500, or a custom error page only for one path.
- Logs mention class loading, missing files, datasource errors, or application exceptions.
If only one application is affected, focus on the WAR package, context path, and application logs. If Tomcat itself does not start, focus on service control, Java runtime, and port checks.
Review the Tomcat and application logs first
Logs usually contain the exact reason a deployment broke. In a hosting environment, this is often the fastest way to identify whether the issue is in the application or in the service configuration.
What to look for in the logs
- Java exceptions during startup, especially stack traces ending in deployment failure.
- Messages about missing libraries, classes, or resources.
- Port already in use errors.
- Permission denied errors for temp, work, or upload directories.
- Datasource or database connection errors.
- OutOfMemoryError, too many open files, or similar resource errors.
Where to find the relevant logs
Depending on the setup, logs may be available in the Tomcat instance directory, in the application's log files, or through the control panel. In a Plesk-based Java hosting setup, check the service logs and the application-specific logs exposed by the extension or the subscription settings.
Useful log files often include:
- Tomcat startup and catalina logs.
- Application logs generated by your app framework.
- Web server error logs if Apache is proxying traffic to Tomcat.
- System or service logs if the JVM fails before Tomcat fully starts.
When reading logs, start from the first error, not the last. The final error is often a symptom, while the initial error shows the root cause.
Verify that the Tomcat service is running
A broken deployment can sometimes be caused by the Tomcat service not running at all. In managed hosting with service controls, this is usually visible from the service status page.
Service checks to perform
- Confirm that the service is started.
- Restart the service after a failed deployment.
- Check whether the service stopped immediately after startup.
- Look for dependency failures if the service comes up and shuts down again.
If the service cannot stay running, there is likely a startup problem in the JVM, configuration, or deployed application. In a private JVM setup, a failed deployment can also stop the instance if the app crashes during initialization.
Check the Java version and Tomcat version compatibility
One common cause of broken Java deployments is a mismatch between the application’s requirements and the Java runtime installed in the hosting account. Some applications require a specific Java release, while older applications may fail on newer runtimes because of deprecated APIs or removed modules.
What to confirm
- The application supports the selected Java version.
- The Tomcat version is compatible with the application and its libraries.
- Any build-time dependencies match the runtime environment.
- The app was not compiled for a newer JDK than the one selected in the hosting panel.
With My App Server, you can often choose from several ready-made Java and Tomcat versions or add a custom setup. If a deployment broke after a version change, test the same application using the previous Java version if possible. A version mismatch often shows up as class loading errors, unsupported class version messages, or module access problems.
Validate the WAR file or application package
If the deployment itself is broken, the package may be incomplete or invalid. A WAR can upload successfully but still fail during extraction or startup if it contains missing files, wrong folder structure, or broken dependencies.
Common package problems
- The WAR is incomplete because the upload was interrupted.
- The archive contains a nested top-level folder that changes the expected structure.
- Required libraries are missing from WEB-INF/lib.
- The application depends on files that are not included in the package.
- The package was built for a different servlet container or framework version.
Practical checks
- Rebuild the WAR from a clean local build.
- Compare the deployed package with a known working release.
- Open the WAR locally and confirm that WEB-INF, classes, and libraries are present.
- Try deploying a minimal test application to confirm the Tomcat instance is healthy.
If a simple test WAR deploys correctly, the problem is almost certainly in the application package rather than the hosting platform.
Confirm the context path and deployment path
A deployment may be technically successful but still appear broken because the application is being opened through the wrong URL. This is especially relevant in Tomcat hosting where the context path is derived from the WAR name or deployment settings.
Things to check
- The WAR filename matches the expected context path.
- The application is being accessed with the correct path and protocol.
- No duplicate context is already using the same URL path.
- The deployment folder does not contain an old version of the same app.
For example, if the app was deployed as myapp.war, the path may be /myapp. If the application expects the root path, but Tomcat is serving it under a subpath, login pages, redirects, or static assets may break.
Also check whether your app uses hardcoded links to absolute paths. A deployment can seem broken after moving from a local environment if links still point to / instead of the application context.
Look for port conflicts and proxy issues
On hosting platforms where Apache is used in front of Tomcat, a deployment may fail to become reachable if the Tomcat port is misconfigured or already in use. In other cases, the application works on the backend but Apache cannot route requests correctly.
Port and proxy checks
- Confirm that Tomcat is listening on the expected port.
- Check whether another service is already using that port.
- Verify that the Apache proxy or connector settings were not changed accidentally.
- Ensure the application is not trying to bind to a restricted or conflicting port.
If a custom app server or private JVM was configured manually, a port mismatch after a restart is a frequent cause of deployment failure. This is especially common when switching between versions or copying settings from one instance to another.
Check file permissions and ownership
Broken deployments on hosted Tomcat are often caused by filesystem permissions. The application may deploy, but it cannot write session data, create temp files, unpack libraries, or load generated content.
Directories that often need attention
- Tomcat temporary directories.
- Work directories used for JSP compilation.
- Application upload directories.
- Log directories.
- Storage directories for cache or runtime files.
Symptoms of permission problems
- 500 errors after first request.
- JSP pages fail to compile.
- Uploads stop working after deployment.
- Logs show access denied or cannot create file messages.
In shared hosting, the application must use writable directories that are allowed by the service configuration. Do not assume that a path writable on a local machine will also be writable on the hosted instance.
Inspect framework-specific startup errors
Many Tomcat deployments fail because the application framework throws an exception during initialization. This is common with Spring, Hibernate, JSF, JSP-based apps, or older servlet applications.
Typical examples
- Missing environment variables or configuration files.
- Database schema not created or not migrated.
- Incorrect datasource JNDI name.
- Broken bean initialization or context loading failure.
- Class path conflicts between bundled libraries and server libraries.
If the application works locally but fails on the hosted Tomcat instance, compare the runtime configuration carefully. Look for differences in:
- Java version.
- Locale and encoding.
- Database credentials.
- File paths.
- External service endpoints.
Hosted environments often expose startup issues that were hidden on a developer workstation because the runtime is cleaner and less forgiving.
Check for memory and resource limits
Small and medium Java applications usually run well in a hosted Tomcat environment, but deployment can fail if the application exceeds the available memory or resource limits of the account.
Resource-related causes
- Heap size configured too high for the hosting plan.
- Too many threads or background workers.
- Excessive class loading during startup.
- Large WAR extraction causing temporary storage pressure.
If the logs show OutOfMemoryError, reduce the JVM memory settings to a level that fits the available service limits. If startup is slow but eventually succeeds, the issue may be a heavy initialization sequence that should be optimized in the application.
Redeploy cleanly instead of overwriting files in place
If a deployment breaks after an update, do not rely only on replacing the WAR file over an existing installation. Old unpacked files can remain in the work directory or application folder and interfere with the new version.
Recommended clean redeploy steps
- Stop the Tomcat service if the hosting panel allows it.
- Remove the old deployment package and unpacked application directory.
- Clear temporary and work files if available.
- Upload a fresh WAR built from a clean source tree.
- Start the service again and test the application URL.
This approach helps avoid stale class files, cached JSPs, and leftover configuration from older releases.
Test with a minimal application
If you are unsure whether the issue is in the hosting service or the application, deploy a very small test app. A simple servlet or JSP page is enough to verify that the Tomcat instance, Java runtime, and web server connection are working.
What this test tells you
- If the test app works, the platform is healthy and your main app needs debugging.
- If the test app fails too, the problem is in Tomcat, Java, permissions, or proxy setup.
- If only static pages work, the issue may be specific to servlet execution or deployment config.
Using a minimal test deployment is one of the most efficient ways to narrow down a broken Tomcat deployment without changing multiple settings at once.
When to use My App Server controls in Plesk
In a Plesk-based hosting environment with My App Server, service control and version selection can solve many broken deployments without manual server access. The extension is useful when you need to:
- Switch to a different supported Java version.
- Restart a private Tomcat service after a failed deployment.
- Check whether a custom app server configuration is still valid.
- Deploy WAR-based applications from the control panel.
- Manage a separate JVM for a Java, JSP, or servlet application.
If you created a custom app server setup, confirm that the configuration still matches the application’s expected Java runtime, port, and memory settings. A custom setup is powerful, but it also means configuration mistakes can break deployment more easily.
Common symptoms and likely causes
- HTTP 404 after deploy: wrong context path, wrong WAR name, or application not extracted.
- HTTP 500 on first request: startup exception, missing config, or runtime dependency problem.
- Tomcat stops immediately: JVM issue, invalid config, port conflict, or fatal deployment error.
- Blank page or redirect loop: bad proxy settings, broken app URL, or session/cookie configuration.
- JSP pages fail only after deployment: compile error, permissions problem, or missing tag libraries.
- Works locally but not on hosting: runtime mismatch, environment variables, file path assumptions, or database access issues.
Step-by-step recovery checklist
- Check the Tomcat service status.
- Read the first relevant error in the logs.
- Confirm the Java and Tomcat version match the application requirements.
- Verify the WAR file is complete and built cleanly.
- Check the context path and deployment URL.
- Review permissions for temp, work, and upload folders.
- Look for port conflicts or proxy issues.
- Test with a minimal application.
- Redeploy cleanly if the previous release may have left stale files behind.
FAQ
Why does my Tomcat deployment work locally but fail on hosted service?
Hosted environments usually have different Java versions, tighter permissions, and separate service settings. The most common causes are missing runtime dependencies, file path assumptions, and configuration differences.
What log should I check first?
Start with the Tomcat startup logs, then the application logs, then the web server error log if Apache is proxying requests. Always look for the first error, not only the final exception.
Can a bad WAR file cause Tomcat to stop?
Yes. If the application fails during initialization or triggers a fatal startup issue, it can prevent the service from becoming usable. A clean rebuild of the WAR is often the quickest fix.
Why am I getting 404 after a successful deployment?
This often means the application is deployed under a different context path than expected, or the archive was not extracted correctly. Check the WAR name, deployment directory, and access URL.
Do I need to reinstall Tomcat every time deployment breaks?
No. In most cases, you can resolve the issue by checking logs, fixing the application package, adjusting Java settings, or redeploying cleanly. A full reinstall is rarely the first step.
What should I do if I changed the Java version and the app stopped working?
Switch back to the previous working Java version if possible, then review compatibility notes for your framework and libraries. Some applications depend on a specific Java release.
Conclusion
A broken Tomcat deployment is usually caused by a small number of predictable issues: an invalid package, a startup exception, a Java mismatch, a permissions problem, or a context path error. In a managed hosting setup with Plesk and My App Server, the best approach is to work from the service level down to the application level: verify the Tomcat service, read the logs, confirm Java compatibility, and redeploy cleanly when needed.
For most startup and deployment failures, you do not need a complex server-side change. A careful check of the WAR, runtime version, logs, and deployment path is often enough to restore service quickly and safely.