When a hosted Java application stops working, the fastest way to find the cause is to check the application logs before changing anything else. In a managed hosting environment, logs usually tell you whether the issue is caused by a failed Tomcat startup, a Java version mismatch, a broken deployment, a missing environment variable, a database connection problem, or a simple application error such as an exception in a servlet or JSP.
If your Java app runs through a control panel such as Plesk with a dedicated service like My App Server, the same rule still applies: start with the logs attached to the Java service, then move to service status, deployment files, and finally application settings. This approach saves time and avoids unnecessary restarts or redeployments.
Check the application log first
The application log is usually the most useful place to begin when a Java hosting service stops responding. It often shows the exact moment the app failed and the reason behind it. Look for:
- Stack traces and uncaught exceptions
- Startup errors from Tomcat or the JVM
- Port binding problems
- Missing classes, libraries, or configuration files
- Database connection failures
- Memory-related errors such as OutOfMemoryError
- Deployment failures after uploading a new WAR file
For hosted Java applications, the log file may be available in your control panel, in the application’s directory, or in the service output generated by the Java process. If your hosting platform uses a custom Java service extension, such as My App Server, the service log is usually the first place to inspect because it captures both the application runtime and the server startup messages.
What to look for in the most recent log entries
Focus on the newest entries first. A Java app can run normally for days and then stop because of a deployment change, a code update, or an external dependency problem. Useful log patterns include:
- SEVERE or ERROR messages
- Java stack traces ending in the root exception
- Messages about failed context initialization
- Warnings about unsupported class versions
- Tomcat startup messages followed by abrupt termination
- Repeated restart loops
If the log ends unexpectedly, that may indicate the process crashed, the service was stopped manually, or the JVM failed during startup.
Confirm whether the Java service is running
Before making changes to the app itself, check the service status in the hosting control panel. In a managed hosting environment, the app may be installed correctly but the service may be stopped, paused, or stuck in a restart loop.
In a Plesk-based Java hosting setup, the service control screen usually shows whether the private JVM or Tomcat instance is running. If the service is down, the log can help you identify whether the issue is a bad configuration, a missing file, or a runtime failure.
Typical service states and what they mean
- Running: the Java process is active, so the problem may be inside the application or its dependencies.
- Stopped: the app is not available because the JVM or Tomcat instance is not active.
- Starting: the service may still be initializing, or it may be hanging during startup.
- Restarting repeatedly: a configuration, deployment, or runtime error is preventing the service from staying up.
If the service is stopped, check the logs first, then restart only after you understand the reason. Restarting too early can hide the original error message if log rotation or truncation occurs.
Read the Tomcat startup log carefully
For hosted Tomcat applications, startup output is one of the most valuable sources of information. Tomcat may start part of the service correctly but fail when loading the web app. That means the server itself may appear available while the application context is broken.
Watch for the following in the startup sequence:
- Java runtime version detected by the service
- Tomcat initialization messages
- Servlet context deployment output
- WAR extraction or unpacking messages
- Classloading or dependency errors
- Connection pool initialization failures
If you see a line indicating that Tomcat started, but then the application fails to deploy, the issue is probably inside the application package rather than the server itself.
Common startup errors in hosted Java environments
- Unsupported major.minor version or class version errors: the app was compiled for a newer Java version than the service uses.
- ClassNotFoundException or NoClassDefFoundError: a required class or library is missing from the deployment.
- BindException: another process may already be using the port.
- Permission denied: the service cannot read or write a required file.
- Port already in use: a manual configuration or custom server setting conflicts with the hosted service.
These issues are especially relevant when using a private JVM or a custom Tomcat installation under a shared hosting account, because the application server settings must match the deployment structure exactly.
Check the application deployment files
If the logs point to deployment problems, review the uploaded files next. A hosted Java app may stop working after a WAR upload, an incomplete JSP deployment, or a broken folder structure. This is common when files are replaced manually or when a build process does not create a clean package.
Inspect the deployment for:
- Missing
WEB-INFcontent - Incorrect
web.xmlconfiguration - Wrong file permissions
- Incomplete WAR upload
- Duplicate libraries in
WEB-INF/lib - Unexpected file names or case-sensitive path issues
If your hosting panel supports application management, compare the current deployed version with the last known working version. A fresh redeploy from a verified build is often the quickest way to confirm whether the application package itself is the source of the issue.
Review Java version and Tomcat version compatibility
One of the most common causes of a hosted Java app failure is a mismatch between the Java version used by the app and the version available in the service. This is especially important in environments that allow you to choose from several ready-made Java or Tomcat versions.
For example, if your application was built for Java 17 but the service runs on an older runtime, the app may fail during class loading or startup. The same can happen if the app expects a newer Tomcat feature or a specific servlet API level.
Questions to ask when the app stops working after an update
- Was the app recently rebuilt with a newer JDK?
- Did the hosting service Java version change?
- Was Tomcat upgraded or switched?
- Did the app begin using a library that requires a different runtime?
- Are JSPs or servlets compiled against a different API level?
In a control-panel-based Java hosting platform, it is often possible to switch the installed Java version or create a new app server instance with a compatible runtime. Always confirm the expected runtime requirements before making changes.
Check for configuration and environment problems
Logs often reveal that the app is not failing because of code, but because of configuration. Missing environment variables, wrong file paths, or incorrect database settings can stop an otherwise valid Java web application from starting.
Pay attention to:
- Database URL, username, and password issues
- Missing configuration files loaded from
WEB-INF/classesor external paths - Incorrect JVM options
- Broken system properties
- Path references that do not exist on the hosting account
- Locale, encoding, or timezone assumptions
Many Java applications depend on environment-specific settings that work in a development server but fail in hosted production because the file system layout is different. When a service like My App Server is used, the logs can show exactly which setting could not be read or which connection could not be established.
Look for resource limits and runtime exhaustion
In hosted Java environments, the app may stop working because it exceeds available resources rather than because of a direct code fault. Logs can show clues such as memory exhaustion, thread starvation, or request timeouts.
Common signs include:
- OutOfMemoryError
- GC pressure or repeated garbage collection warnings
- Request timeouts during startup or loading
- Thread pool exhaustion
- Slow database calls causing startup to stall
- Large log bursts just before the service becomes unavailable
If you suspect resource exhaustion, check the service usage information in the control panel and compare it with your application’s normal load. For small and medium Java, Tomcat, JSP, or servlet applications, performance issues are often caused by code paths that load too much data too early or by accidental infinite loops.
Use log timestamps to narrow down the trigger
A practical way to diagnose a stopped Java app is to compare timestamps in the logs with recent changes. Ask what happened just before the failure:
- Was a new WAR deployed?
- Were server-side settings edited?
- Did the Java version change?
- Was the application restarted manually?
- Did a database password or endpoint change?
The timestamp often tells you whether the failure happened immediately after deployment, during a scheduled restart, or after the app received a specific request. This helps separate startup failures from runtime failures.
How to isolate the problem safely
If the log does not immediately show the root cause, use a simple isolation method instead of changing several settings at once.
- Check the latest error in the application log.
- Confirm whether the Java service is running in the control panel.
- Review the most recent deployment or file upload.
- Compare the active Java and Tomcat versions with the app requirements.
- Inspect configuration files and environment settings.
- Restart the service only after you have captured the relevant log entries.
- Test with the last known working version if available.
This approach is especially useful in managed hosting, where the control panel provides clear service management but the application itself still requires careful troubleshooting.
What to collect before contacting support
If you need help from the hosting provider, sending the right information speeds up the investigation. Include:
- The exact time the app stopped working
- Relevant log entries from before and after the failure
- The app name and deployment type, such as WAR, JSP, or servlet app
- The Java version and Tomcat version in use
- Any changes made just before the issue
- The service status shown in the control panel
If the app uses a custom Java service under a hosting panel, mention whether the service was installed from a ready-made version or configured manually. That can help identify whether the issue is related to the runtime setup or to the application package itself.
Practical checklist for a stopped hosted Java app
Use this checklist when the application no longer responds:
- Open the application or service log
- Read the newest error entries first
- Check whether the Java service is running
- Confirm the Tomcat startup result
- Review recent deployment changes
- Verify Java and Tomcat compatibility
- Check configuration files and environment settings
- Look for memory, thread, or timeout errors
- Compare timestamps with the last update
- Collect evidence before restarting or redeploying
FAQ
Why should I check logs before restarting the app?
Because a restart can overwrite or advance the log state and make the original failure harder to identify. The log usually contains the real cause, especially for startup or deployment problems.
What if the service is running but the app still does not work?
That usually means Tomcat or the JVM is up, but the application context failed to load or one of its dependencies is broken. Check the app log for exceptions, class loading issues, or database connection errors.
Can a Java version mismatch stop the app completely?
Yes. If the application was compiled for a newer Java runtime than the hosted service provides, it may fail to start or crash during loading.
Should I redeploy the WAR file right away?
Only after checking the logs. If the error is caused by configuration, Java version, or permissions, redeploying the same package will not help and may make troubleshooting harder.
What log message usually points to a missing library?
Messages such as ClassNotFoundException or NoClassDefFoundError often indicate that a required dependency is missing from the deployment or not packaged correctly.
What if I cannot find the cause in the logs?
Check the exact service status, confirm recent changes, and compare the current Java/Tomcat version with the application requirements. If needed, collect the relevant log snippets and contact support with the failure time and deployment details.
Conclusion
When a hosted Java app stops working, the best first step is almost always the same: read the logs. In a Plesk-based Java hosting environment with a managed service such as My App Server, the logs can quickly show whether the problem is in the runtime, the Tomcat service, the deployment package, or the application configuration.
By checking the latest log entries, confirming service status, reviewing version compatibility, and comparing the failure time with recent changes, you can narrow down the issue much faster and avoid unnecessary restarts. For Java hosting, Tomcat hosting, JSP hosting, servlet hosting, and private JVM setups, this is the most reliable way to identify why the application stopped working.