If a hosted JSP application suddenly stops working, the fastest way to find the cause is usually in the logs. In a typical Java hosting setup with Plesk and My App Server, the problem is often not the JSP file itself but something around it: a Tomcat startup error, a Java version mismatch, a missing library, a permissions issue, or an application exception that only appears in the runtime logs. For UK hosting customers, the same troubleshooting approach applies whether the app is a simple JSP site, a servlet-based application, or a small private JVM deployment managed through the control panel.
Before changing anything else, start by checking whether the service is running, then read the application and server logs in the right order. This saves time and helps you avoid guesswork.
What to check first when a JSP app stops responding
When a hosted JSP app is down, begin with the basic health checks. These are the most common starting points in a Plesk-based Java hosting environment:
- Is the My App Server service running?
- Did the Tomcat instance restart unexpectedly?
- Are there recent error messages in the application log?
- Did the app deploy cleanly after the last upload?
- Has the Java version changed or become incompatible?
- Is the issue happening for all users or only one path, page, or action?
If the app stopped after a change, the last deployment is usually the best place to begin. If it stopped without a deployment, look for service restarts, crashes, or resource limits before assuming the code is broken.
Open the service status in Plesk first
In a managed hosting setup, the control panel often gives the quickest signal about whether the problem is application-related or service-related. With My App Server, you can usually confirm whether the Java service and the private JVM are up, stopped, or restarting.
Why service status matters
If the app server is stopped, the website may show a connection error, an HTTP 503 response, or an empty page rather than a clear Java stack trace. In that case, logs will often show the reason for the stop: a startup error, memory issue, invalid configuration, or a failure while loading the app server.
In Plesk, check:
- Service state for the Java app server
- Recent restart time
- Whether the app was manually restarted
- Any service-control messages or warnings
If you are using a hosted Tomcat instance created through My App Server, a failed service start can prevent every JSP page in that app from loading, even if the code itself is fine.
Which logs to read first
Do not start with the longest or oldest log. Start with the logs that are most likely to show the immediate cause.
1. Application error log
This is the first place to look when a JSP page fails, a servlet throws an exception, or deployment breaks. Search for:
- Java stack traces
- ClassNotFoundException
- NoClassDefFoundError
- Servlet initialization errors
- JSP compilation errors
- NullPointerException near the failing request
- Database connection failures
A stack trace usually points to the exact class, method, or JSP line that failed. If the log shows a line number in a JSP file, that is often the fastest clue.
2. Tomcat or container startup log
If the app server is not starting or keeps restarting, the startup log is critical. It may show:
- Invalid XML or configuration syntax
- Port conflicts
- Bad context configuration
- Missing environment variables
- Broken library loading
- Java version incompatibility
This log is especially useful after a Java version switch or when a custom Tomcat version was uploaded manually.
3. Web access log
The access log shows what users are requesting and what HTTP status code is returned. This is helpful when the app is technically running but still not behaving correctly.
Look for:
- 404 for specific JSP or servlet paths
- 500 errors on one endpoint
- 503 errors when the service is unavailable
- Repeated requests from one browser or bot
- Odd redirects or loops
If only one page fails, the access log helps you confirm whether the request reaches the app at all.
4. System or service log
If available in your hosting plan or control panel, system-level messages can explain crashes caused by resource limits, out-of-memory events, or forced restarts. These logs are often the best source for issues that are not visible inside the application itself.
How to read a JSP error in practice
Many hosted JSP issues produce a stack trace. The important part is not to read every line first, but to identify the first meaningful error. Usually, the top of the stack shows the real cause, while later lines show the chain of calls that led to it.
Common patterns and what they often mean
- ClassNotFoundException or NoClassDefFoundError — a missing JAR, incorrect library path, or dependency not deployed with the app.
- JSP compilation error — syntax problem, missing tag library, or incompatible code in the JSP page.
- HTTP 500 with a stack trace — application logic error, failed database call, or unhandled exception.
- HTTP 503 — app server unavailable, not started, or overloaded.
- Permission denied — file, folder, or upload rights do not match what Tomcat needs.
- OutOfMemoryError — the private JVM ran out of memory or the app is using more resources than expected.
In a shared hosting account with a private JVM, a memory or startup problem may look like a broken website from the outside. The logs tell you whether the service itself is healthy enough to serve requests.
Step-by-step: diagnose the failure from logs
Step 1: note the exact time the issue started
Try to match the time of the failure with a log entry. If the site stopped after a deployment at 14:20, focus on entries from that moment onward. This is often the fastest way to connect a change to an error.
Step 2: confirm whether the service restarted
If the service restarted just before the issue, look at the startup log first. A restart can leave clues such as:
- automatic service recovery
- startup failure after configuration changes
- reloaded app context with missing files
- Java process termination before full boot
Step 3: search for the first error, not every warning
Warnings are common and not always relevant. Focus on the first error that appears before the app stopped working. A later stack trace may only be a symptom of an earlier failure.
Step 4: compare the failing request with a working one
If one JSP page fails but others still work, compare the request path, the parameters, and the code path. The access log can tell you whether the same URL is repeatedly failing or whether the issue is tied to a specific form submission, session state, or backend call.
Step 5: test whether the problem is application-wide or page-specific
Open a static page, a health endpoint, or another JSP page in the same app. If only one page fails, the problem is likely in that view or its underlying logic. If all pages fail, the issue is more likely with the servlet container, deployment, or JVM.
Typical log causes in hosted Tomcat and JSP environments
In Java hosting, the same small set of problems appears again and again. Knowing them makes log reading much faster.
Missing or incompatible libraries
If the application was deployed with the wrong JAR files, the log may show class-loading failures. This is common after manual uploads, when the app works locally but not in hosting because a dependency was left out.
Java version mismatch
Some applications run only on specific Java versions. If the app server was created with one Java version and the app expects another, startup or runtime errors may appear immediately. This is one of the main reasons to check the selected Java version in My App Server before changing code.
Broken deployment package
A WAR upload can fail if the archive is incomplete, corrupted, or built incorrectly. Logs may show deployment exceptions, missing descriptors, or failure to unpack the application.
Incorrect file permissions
If Tomcat cannot read the web application, write session data, or access logs, you may see permission-related errors. This is especially relevant when files were uploaded manually or replaced outside the normal deployment flow.
Configuration errors
A small typo in XML, a bad context path, or an invalid setting in a Tomcat configuration file can stop the whole app from loading. Startup logs are the best place to find these issues.
Database connection issues
Many JSP applications fail because the database is not reachable, credentials changed, or the connection pool cannot initialise. In the log, this may appear as connection refused, authentication failure, timeout, or driver loading errors.
How My App Server helps with troubleshooting
In the ITA Java hosting environment, My App Server is designed to make Tomcat and private JVM management easier from Plesk. That matters during troubleshooting because you can often check the service, select the Java version, and restart the app server from the same place.
Useful actions include:
- checking whether the app server is running
- restarting the service after a failed deploy
- switching to a compatible Java version if needed
- reviewing logs attached to the app server
- confirming the installed Tomcat version
If you use a custom app server version, logs are even more important because manual setups can introduce configuration differences that are not obvious in the interface. When an app stops working after a custom change, compare the current service state with the last known good setup.
What to do after you find the error
Once the log points to a likely cause, take one corrective action at a time. This keeps troubleshooting clean and makes it easier to see whether the change fixed the problem.
- If the log shows a missing class, verify that the required JAR is deployed.
- If the log shows a compile error, fix the JSP syntax or taglib reference.
- If the log shows a Java version mismatch, select a supported version for the app.
- If the log shows a permissions issue, correct file access for the app files and runtime paths.
- If the log shows a database error, test the datasource, credentials, and network reachability.
- If the log shows a crash or out-of-memory condition, review the app size and JVM settings.
After each change, restart the app server if needed and re-check the log. A clean restart and a fresh test request are often enough to confirm whether the issue is resolved.
Best practice for reading logs in a managed hosting account
For hosted JSP and Tomcat apps, a disciplined log-reading process saves time and avoids unnecessary changes.
- Start with the timestamp closest to the failure.
- Check service status before editing files.
- Read the first error, not only the final exception.
- Use the access log to confirm the request path and HTTP code.
- Compare a broken page with a working one in the same app.
- Restart only after you understand the likely cause.
- Keep a copy of the previous working deployment when possible.
This approach is especially useful in shared hosting environments where the app server, JVM, and control panel settings are closely linked. A small change in one place can affect the whole application.
When the logs are not enough
Sometimes the logs show symptoms but not the root cause. If that happens, check the following:
- recent file changes in the application directory
- upload completion and archive integrity
- changes to Java version or runtime options
- external dependencies such as database or API availability
- whether the issue started after a cache or session-related change
If you still cannot identify the cause, collect the exact error message, the time of failure, the affected URL, and the steps you already tried. That makes it much easier to continue troubleshooting without repeating the same checks.
FAQ
Why does my JSP app show HTTP 500 but no clear page error?
HTTP 500 usually means the server received the request but the application failed while processing it. The application error log or Tomcat log should contain the real exception, such as a Java stack trace or a missing dependency.
What log should I check if the app server will not start?
Begin with the Tomcat or startup log, then check the service status in Plesk. If startup fails before the app is fully loaded, the error is often recorded there first.
How do I know if the problem is caused by Java version compatibility?
If the log mentions unsupported classes, JVM errors, or startup failures after a version change, compatibility is likely involved. Compare the Java version selected for the app server with the version required by your application.
Can one broken JSP file stop the whole app?
Yes. If the page is compiled or loaded during startup, a single JSP problem can affect the application. If the error is only on one route, the rest of the app may still work.
Should I restart the service before checking logs?
Usually no. Check the logs first so you do not lose the most useful error messages. Restart after you understand the failure, unless the service is clearly already down and you need to confirm startup behaviour.
What if I only see warnings in the logs?
Warnings are not always the cause of a failure. Look for the first actual error and the timestamp that matches when the problem began. Many issues are caused by an earlier line that looks less dramatic than the final exception.
Conclusion
When a hosted JSP app stops working, the fastest fix usually starts with logs, not with random changes. Check service status in Plesk, read the application and startup logs in time order, and use the access log to confirm what the user actually sees. In a My App Server setup, this approach is especially practical because you can manage Tomcat, Java version selection, and service control from one place. Once you identify the first real error, the next step is usually straightforward: repair a missing dependency, correct configuration, adjust permissions, or align the Java runtime with the application’s needs.