If a hosted Java app suddenly stops working, the fastest way to narrow down the cause is to check the right logs in the right order. In a managed hosting environment, especially when you are running Java through Plesk and a private Tomcat or JVM service, the problem is often not in the application code alone. It may be a failed service start, a bad deploy, a configuration change, a Java version mismatch, a resource limit, or a web server issue in front of the app.
For UK hosting users, the practical approach is the same whether you are running JSP, servlets, or a WAR-based Tomcat app: start with the application logs, then check the service logs, then verify the control panel status and any reverse proxy or Apache integration. This article explains where to look first, what each log usually tells you, and how to quickly separate a Java application problem from a hosting or service problem.
What usually breaks first when a Java app stops responding
When a hosted Java app goes down, the visible symptom is often one of these:
- The site returns a 500 error.
- The app shows a blank page or never finishes loading.
- The Tomcat service is running, but the application is not available.
- The app starts after deployment, then fails on the first request.
- Changes to Java code, web.xml, or server configuration cause the app to stop.
In a Plesk-based Java hosting setup such as My App Server, those symptoms usually map to one of four areas:
- Application errors in your Java or Tomcat logs.
- Startup failures in the service log or Tomcat catalina log.
- Deployment issues with the WAR file, context path, or permissions.
- Resource or platform limits such as memory, disk space, or process restrictions.
If you check logs in a random order, you can waste time. The sections below show the best sequence for hosting support and self-diagnosis.
Start with the application log, not the browser error
The browser message is only the symptom. The application log is usually the first place to find the real cause. In Java hosting, this may include:
- Tomcat application logs
- Servlet stack traces
- JSP compilation errors
- Framework startup errors
- Database connection failures
What to look for in the log
Search for the first error around the time the app stopped working. Common patterns include:
- Exception in thread messages
- Caused by lines further down the stack trace
- ClassNotFoundException or NoClassDefFoundError
- OutOfMemoryError
- Port already in use
- Permission denied
- Failed to bind or connection refused
If the application log shows a stack trace, do not stop at the top line. The most useful clue is usually the lowest Caused by entry, because that is often the real root cause.
Typical examples
- ClassNotFoundException: a missing JAR, incorrect build, or broken deployment package.
- SQLException: database host, credentials, firewall rule, or schema issue.
- JSP compilation error: syntax mistake, missing import, or incompatible Java version.
- OutOfMemoryError: the app needs more heap than the current JVM settings allow.
If you are using My App Server, the app log is especially valuable because it shows whether the problem is inside the Java application itself or caused by the Tomcat/JVM service that hosts it.
Check the Tomcat and Java service logs next
If the app log is empty or the app never starts, move to the service-side logs. In managed hosting, a Java app can fail before it ever reaches your code. That means you need to inspect the service startup messages and the Tomcat log.
Why service logs matter
Service logs tell you whether the Java runtime, Tomcat process, or app server started correctly. They can reveal:
- Java version problems
- Invalid startup options
- Missing environment variables
- Bad context configuration
- Failure to create temp directories
- Unexpected shutdowns and restarts
In a Plesk control panel environment, service control is often handled through the hosting interface rather than the command line. If the app server is stopped, restarting it from the panel may give you a fresh log entry that points to the exact issue.
Common service log clues
- Address already in use: another process is using the required port.
- Could not create the Java Virtual Machine: invalid JVM option or memory setting.
- Unsupported major.minor version or similar: Java version mismatch.
- Deployment descriptor error: bad app configuration or malformed XML.
- Service exited unexpectedly: the process started, then crashed quickly.
For hosted Java apps, a service log failure often means the app is not even reaching the web layer. This is why checking the service first can save time when the app is fully down.
Use the control panel status to separate app, service, and web server issues
In a managed hosting setup, the control panel is not just for starting and stopping services. It also helps you see whether the issue is local to the app server or broader than that.
What to verify in Plesk or the hosting panel
- Is the Java service running?
- Was it recently restarted?
- Did the deployment complete successfully?
- Has the app path or context changed?
- Are there disk usage warnings or resource alerts?
If the panel shows the service as running but the website is still unavailable, the next likely cause is inside the app, the deployment, or Apache integration in front of the application.
If the panel shows the service stopped, focus on why it stopped rather than on the browser error. The service log is usually more useful than the web page response.
Do a quick Apache and reverse proxy check when the app is behind web server routing
In many hosted Java setups, Apache sits in front of Tomcat or another internal app server. That means the Java app may be healthy, but the web server routing is wrong. This is common after a context change, rewrite update, certificate change, or port adjustment.
What to check
- Whether Apache is returning the error before the request reaches Tomcat
- Whether the virtual host or proxy rule still points to the correct backend
- Whether SSL or redirect rules were changed
- Whether the app context path matches the deployed application
Signs that Apache or proxy routing is the issue include:
- Apache 502 or 503 errors
- Generic gateway messages instead of a Java stack trace
- Static pages working, but the Java app endpoint failing
- The Tomcat service appears healthy, yet the public URL is wrong
If you can access the app directly on its backend route and it works there, the problem is likely in Apache or the routing layer rather than the Java code itself.
Check the deployment package and permissions
A surprising number of Java hosting issues come from a broken deploy, not from the code that was previously working. This is especially true after uploading a new WAR file or changing the application structure.
Review these items first
- Was the correct WAR file uploaded?
- Did the upload finish fully?
- Was the old deployment removed cleanly?
- Are file permissions correct for the app directories?
- Does the app have write access to temp, logs, or upload folders?
In hosted environments, the app may fail if it cannot write to a required folder. This can happen after a permissions change, a new release, or a restoration from backup.
Logs that point to deployment problems
- FileNotFoundException for a resource that should exist
- Permission denied for a cache, temp, or upload directory
- XML parsing errors in web.xml or context files
- Failed to load class after a missing JAR or broken package
If the app worked before and stopped immediately after deployment, the deployment package is one of the first things to inspect.
Look for Java version and compatibility errors
When you use a hosting platform that lets you choose or install different Java versions, compatibility becomes important. A working app can fail after a Java upgrade or after moving to a different Tomcat setup.
Typical version-related symptoms
- App starts on one Java version but not another
- JSP compilation fails after an update
- Libraries compiled for a newer Java release do not run on the selected JVM
- Tomcat starts, but the application throws class loading errors
Look for messages such as:
- UnsupportedClassVersionError
- Unsupported major version
- Java.lang.NoSuchMethodError
These often mean the application was built for a different Java runtime than the one currently selected in My App Server.
Check disk space, memory, and hosting limits
Resource problems are easy to miss because the app may work under light traffic and fail only when load increases. In shared Java hosting, practical limits matter.
Resource-related clues in the logs
- OutOfMemoryError or GC overhead limit exceeded
- No space left on device
- Too many open files
- Cannot allocate memory
- Repeated restarts without a clear application exception
Check whether the account is near disk usage limits, whether log files have grown too large, and whether the JVM heap configuration is realistic for the application size. A private JVM is useful for control and isolation, but it still needs sensible tuning.
If the app is memory-sensitive, watch for sudden spikes during startup or at peak request times. A Java service may appear healthy until a large deployment, batch job, or report generation runs.
Use a simple log-reading method that works in support cases
When you are under time pressure, use this order:
- Check the app log for the first error at the failure time.
- Check the Tomcat or service log for startup or shutdown issues.
- Confirm the service status in Plesk or the hosting panel.
- Verify deployment and permissions after any recent release.
- Check Apache or proxy logs if the public URL fails but the service is running.
- Review resource usage if the logs mention memory, disk, or process limits.
This sequence helps you move from the most specific evidence to the broader hosting layer. In practice, that is faster than jumping straight to code changes or reinstalling the app server.
How to describe the problem when contacting hosting support
If you need assistance, provide focused details from the logs. That helps support identify whether the issue is in the Java app, the Tomcat service, or the hosting configuration.
Include the following information
- The time the app stopped working
- The exact error message or stack trace
- Whether the service is running in the control panel
- Any recent deployment, Java version, or configuration change
- The affected URL or context path
- Whether Apache or the app server log shows the first failure
Do not send only a screenshot of the browser error if you can avoid it. A text excerpt from the log is much more useful.
Practical examples of what the logs may mean
Example 1: 500 error after a new WAR upload
If the app fails immediately after deployment and the log shows a missing class or XML parsing issue, the package is likely incomplete or malformed. Rebuild the WAR, confirm dependencies are included, and redeploy.
Example 2: Service starts, then stops after a few seconds
This often indicates a JVM option problem, memory issue, or startup exception. Check the service log first, then the app log if the service gets far enough to initialize the application.
Example 3: Browser shows gateway error, Tomcat looks healthy
This often points to Apache routing or reverse proxy settings. Verify the backend target, context path, and any recent rewrite or SSL changes.
Example 4: App works after restart, then fails under load
This suggests a resource limit, thread exhaustion, database pool issue, or memory pressure. Review heap settings, connection pools, and the relevant runtime log entries.
FAQ
Where should I look first if my hosted Java app stops working?
Start with the application log for the exact failure time. If that is not enough, check the Tomcat or service log, then verify service status in the control panel.
What if there is no error in the application log?
That usually means the app never reached the point where it could log the failure, or the problem is in the service, routing, or deployment layer. Check the Tomcat/service log and Apache logs next.
How do I know if it is a Java problem or a hosting problem?
If the log shows a Java exception, class loading problem, or startup failure inside Tomcat, it is likely app-side. If the service will not start, the port is busy, or Apache returns a gateway error, it may be hosting or configuration related.
What does UnsupportedClassVersionError mean?
It usually means the application or a library was compiled for a newer Java version than the JVM currently selected in your hosting account.
Can a permission issue break a Java app?
Yes. If the application cannot read configuration files, write to temp directories, or create logs and uploads, it may fail at startup or during request handling.
Why does the app work in one environment but not after deployment?
Common reasons include missing dependencies, a different Java version, broken file permissions, a changed context path, or an incomplete deployment package.
Conclusion
When a hosted Java app stops working, the best first step is not to guess. Read the logs in the right order: application log, service or Tomcat log, control panel status, then Apache or proxy logs if needed. In a Plesk-based Java hosting setup with My App Server, this approach quickly shows whether the issue is in the code, the runtime, the deployment, or the hosting configuration.
For JSP, servlet, and Tomcat-based apps, careful log reading is usually the fastest way to restore service and avoid unnecessary changes. If you build the habit of checking the first meaningful error, you will solve most hosting incidents much faster.