If a Java application suddenly stops loading, returns a 500 error, or shows a broken page, the cause is usually one of a small number of issues: the app server is not running, the Java version does not match the application, a deployment was incomplete, or the application is failing at startup because of a configuration, database, or file permission problem. In a managed hosting environment, the fastest way to diagnose the issue is to check the app server status, review the application logs, and confirm that the Tomcat or JVM configuration still matches the application requirements.
On a hosting platform with Plesk and a Java extension such as My App Server, you can usually isolate the problem without full server access. That is especially useful for Java hosting, Tomcat hosting, JSP hosting, and servlet hosting, where a private JVM and a separately managed Apache Tomcat instance make it easier to see whether the issue is in the app, the runtime, or the deployment path.
Common signs of a broken Java application
Before you start troubleshooting, identify the exact symptom. Different errors point to different causes.
- HTTP 500 Internal Server Error – often means the application threw an exception or failed to start.
- HTTP 404 Not Found – may mean the app is not deployed, the context path is wrong, or the web application was removed.
- Blank page – often caused by frontend errors, failed JSP compilation, missing resources, or an application crash before rendering.
- Tomcat service appears stopped – usually indicates a startup failure, port conflict, or invalid JVM/app configuration.
- Application works after restart but fails later – often points to memory pressure, resource leaks, expired sessions, or external dependency problems.
If the problem affects only one application in the account, focus on deployment and app-specific logs first. If all Java applications are affected, check the shared runtime, service status, Java version, and recent platform changes.
Step 1: Confirm whether the app server is running
The first thing to check is whether the Tomcat instance or private JVM is actually online. In Plesk-based Java hosting, the service status is usually visible from the control panel or from the My App Server extension.
What to check
- Is the service marked as running?
- Did the service stop immediately after a restart?
- Are there any warnings in the service control screen?
- Was a recent configuration change applied before the issue started?
If the service fails to start, the cause is often in the startup logs, not the application homepage. A common pattern is a broken Tomcat configuration, a Java version mismatch, or an application that prevents startup because of an exception during initialization.
Typical startup-related causes
- Wrong Java version selected for the application
- Invalid context configuration or server.xml setting
- Port conflict with another service
- Malformed WAR or incomplete deployment
- Application initialization error in a servlet, filter, or listener
Step 2: Check the application logs
Logs are usually the fastest way to identify the cause of a broken Java application. Look for stack traces, startup exceptions, class loading errors, missing resources, or database connection failures.
Where to look
- Tomcat logs such as catalina.out, catalina logs, and startup logs
- Application-specific logs created by the app itself
- Plesk or My App Server logs showing service start and stop events
- Web server logs if Apache is proxying requests to Tomcat
What to search for
ExceptionCaused byClassNotFoundExceptionNoClassDefFoundErrorOutOfMemoryErrorBindExceptionFileNotFoundExceptionSQLException
When reading logs, focus on the first real error in the chain. Later messages are often the result of the initial failure. For example, a missing class can cause a servlet to fail, which then causes Tomcat to return 500 errors across the whole application.
Step 3: Verify the Java version
One of the most common reasons for a broken Java application is a Java runtime mismatch. The app may have been built for an older or newer Java version than the one currently selected in the hosting panel.
What to confirm
- The application’s required Java version
- The active Java version in My App Server or the hosting panel
- Whether the app was recently upgraded or redeployed
- Whether libraries compiled for a different Java release are being loaded
A modern app can fail if it uses APIs not available in the selected JVM. The opposite can also happen: an older application may break when run on a newer runtime if it depends on deprecated behavior or unsupported libraries.
If your hosting platform allows switching between several ready-made Java/Tomcat versions, test the application with the version recommended by the software vendor or the application documentation. If the app needs a custom Java version, confirm that it was installed and configured correctly before testing further.
Step 4: Confirm that the deployment is complete
A broken app is often the result of an incomplete deployment rather than a code problem. This is especially common after uploading a WAR file, replacing JSP files, or updating static resources.
Check the deployment path
- Is the WAR file fully uploaded?
- Was the archive expanded correctly?
- Is the application deployed under the expected context path?
- Are all required folders and resources present?
If the application loads partially or shows a 404 for some pages, the context path may not match the URL being requested. If a single JSP file is missing, the rest of the application may still work but specific links will fail.
Common deployment mistakes
- Uploading the wrong WAR file version
- Leaving an old exploded directory in place
- Deploying to the wrong context
- Missing libraries inside WEB-INF/lib
- Broken relative paths in JSP or servlet mappings
When in doubt, redeploy from a clean state. Remove the incomplete deployment, upload the correct package again, and restart the service if the hosting platform recommends it.
Step 5: Look for Java class and library problems
If the application starts but fails when a page is requested, classpath issues are a strong possibility. Java web apps depend on the correct set of JAR files, and even one missing dependency can break the runtime.
Symptoms of classpath issues
- HTTP 500 errors only on certain pages
- Errors after a recent code update
- Servlets or filters no longer loading
- Startup errors mentioning missing classes or methods
Typical causes
- Missing JAR in WEB-INF/lib
- Library version conflict
- Duplicate classes packaged in multiple locations
- Application compiled against a different framework version
In a private JVM hosting setup, keep the runtime environment as simple as possible. Avoid adding unnecessary libraries globally unless the app truly needs them. For small and medium web applications, a clean per-app deployment is usually easier to troubleshoot than a shared classpath approach.
Step 6: Check database connectivity
Many broken Java applications are actually database connection failures. The homepage may load, but login pages, dashboards, and search functions can fail when the database is unavailable or the credentials are wrong.
What to verify
- Database hostname, username, password, and schema name
- Whether the database service is reachable from the application
- Whether the connection pool is exhausted
- Whether the application is timing out during startup
In logs, look for SQL exceptions, connection refused messages, authentication failures, or timeout errors. If the app worked until a password change or database migration, update the application settings and restart the app server after applying the change.
Step 7: Review file permissions and ownership
Java applications often need write access to upload folders, temporary directories, cache paths, and log directories. If permissions are wrong, the app may still open but fail when trying to save a file or generate a page.
Check these locations
- Upload directories
- Session and temp folders
- Log directories
- Image or document storage paths
Permission issues commonly appear after a migration, manual file upload, or restore from backup. If the application used to work and then suddenly began returning errors, compare the ownership and permissions of recently changed files and folders.
Step 8: Check memory usage and JVM limits
If the app runs for a while and then becomes unstable, memory limits may be involved. Small Java hosting plans are designed for light to medium workloads, so an app that was sized too aggressively can run out of heap or exceed resource limits.
Possible symptoms
- Application becomes slower over time
- Random 500 errors after traffic increases
- Tomcat restarts unexpectedly
- OutOfMemoryError in logs
What to do
- Check heap and JVM arguments in the app server configuration
- Reduce unnecessary background tasks inside the application
- Review session usage and object caching
- Look for memory leaks in the application code
If your hosting plan has documented service limits, compare them with the application’s actual needs. If the app is regularly hitting the limits, you may need to optimize the application or adjust the deployment rather than repeatedly restarting the service.
Step 9: Inspect Apache and proxy settings if applicable
In many hosting setups, Apache sits in front of Tomcat and forwards requests to the Java application. If Apache or the proxy configuration is incorrect, the app may look broken even when Tomcat is running.
Check for
- Wrong proxy target or connector configuration
- Conflicting rewrite rules
- Changed domain or virtual host settings
- Broken SSL or HTTPS forwarding
If the app behaves differently over HTTP and HTTPS, review the proxy and SSL configuration. A redirect loop, incorrect base URL, or missing forwarded headers can make the site appear broken while the backend is still healthy.
Step 10: Reproduce the problem with a clean test
To separate an application bug from a hosting or configuration issue, test with a minimal request.
Recommended checks
- Open the application root URL in a private browser window
- Request a known working JSP or servlet endpoint
- Test a static file inside the app if available
- Compare behavior before and after a restart
If a simple endpoint works but a specific feature fails, the issue is probably in the application code, not the hosting layer. If all endpoints fail at once, focus on the runtime, deployment, or proxy layer.
How to narrow down the root cause quickly
A practical order of investigation is usually:
- Check whether the service is running.
- Read the latest error in the log file.
- Confirm the Java version.
- Verify the deployment path and WAR contents.
- Test database access.
- Check permissions and write access.
- Review memory and JVM settings.
- Inspect Apache or proxy configuration if the app is behind one.
This approach works well for most Plesk-based Java hosting environments because it separates platform issues from application issues early. The goal is not to guess, but to find the first point of failure.
Examples of common error patterns
Example 1: 500 error after a new deployment
If the application broke immediately after uploading a new WAR, the likely causes are an incomplete upload, missing dependency, or incompatible Java version. Check the startup log first, then redeploy the package cleanly.
Example 2: 404 after a domain or context change
If the homepage returns 404 but Tomcat is running, the context path may have changed or the application may not be deployed under the URL you are testing. Confirm the deployed path in the hosting panel.
Example 3: App works in the morning, fails later in the day
This often points to memory pressure, a database connection pool problem, or a background task that eventually fails. Review logs around the time the app stopped responding.
Example 4: JSP pages fail but static assets load
This usually suggests JSP compilation issues, missing Java libraries, or a servlet container configuration problem rather than a full site outage.
When to restart the service
A restart can help if the application was deployed recently, the JVM is in a bad state, or a temporary lock or memory issue is suspected. However, restarting without checking the logs may hide the real cause.
Restart the service when:
- A fresh deployment was completed and needs reload
- The JVM is stuck or unresponsive
- You changed Java version, memory settings, or context configuration
- The application needs a clean startup after fixing a known issue
Do not use restart as the only troubleshooting step if the same error returns every time. Persistent failure means there is still an underlying problem.
FAQ
Why does my Java application show 500 errors but Tomcat is running?
That usually means the service is up, but the application itself is failing. Check the app logs for exceptions, classpath problems, database errors, or a bad deployment.
Why does my application return 404 after deployment?
The app may be deployed under a different context path, or the WAR may not have expanded correctly. Confirm the deployment location in the hosting control panel and verify the URL you are using.
How do I know if the Java version is wrong?
If the logs mention unsupported classes, version-specific APIs, or startup failures after a Java update, the selected runtime may not match the application requirements. Compare the active Java version with the app’s documentation.
Can a missing JAR file break only one page?
Yes. If that page depends on a specific servlet, bean, or library, the rest of the app may still work while that page throws a 500 error.
What if I cannot find the error in the logs?
Check whether logging is enabled for the application and make sure you are looking at the latest log file. If the service restarts often, the relevant error may be in an earlier log rotation file.
Should I reinstall Tomcat if the app is broken?
Usually no. Start by checking the logs, deployment, Java version, and configuration. Reinstalling the runtime is rarely necessary unless the service itself is damaged or misconfigured.
Is this setup suitable for small Java web apps?
Yes. A hosting setup with a private JVM and managed Tomcat is well suited to smaller Java applications, JSP sites, servlet-based apps, and WAR deployments that need direct control in Plesk.
Conclusion
To find the cause of a broken Java application, begin with the service status, then move to logs, Java version, deployment integrity, database connectivity, permissions, and memory settings. In a Plesk-based Java hosting environment with My App Server, this process is usually straightforward because the app server, JVM, and deployment can be reviewed from one place.
If the error appears after a deployment, focus on the package, libraries, and context path. If it appears over time, focus on memory, database connections, and background processing. If the service does not start at all, the problem is usually in startup configuration or runtime compatibility. Following this order will help you identify the root cause faster and restore the application with less guesswork.