How to troubleshoot a 500 error on Java hosting in the UK

If your Java site returns a 500 Internal Server Error, the problem is usually inside the application, the Tomcat configuration, or the Java runtime that is serving it. On managed Java hosting, the fastest way to fix it is to check the application logs first, then verify the app server status, Java version, deployment package, and any recent changes in Plesk.

A 500 error means the server tried to process the request but failed before it could return a proper response. For Java hosting, that often points to one of these areas:

  • a broken WAR deployment
  • a missing or invalid file in the application
  • a startup failure in Tomcat
  • an incompatible Java version
  • wrong permissions on application files or folders
  • a configuration error in web.xml, context settings, or environment variables

If you are using a Plesk-based Java hosting platform with a private JVM or Tomcat service, you can usually isolate the cause without changing the whole hosting account. The key is to troubleshoot methodically.

What a 500 error means on Java hosting

In a Java environment, HTTP 500 is a generic server-side error. The browser only sees that the request failed, but the real reason is usually logged in Tomcat, the application logs, or the service logs for your app server.

On a hosting platform that supports Java hosting, Tomcat hosting, JSP hosting, and servlet hosting, the 500 error may appear when:

  • Tomcat starts, but the web application fails during initialization
  • the app compiles or loads JSP pages incorrectly
  • the app cannot connect to a database or external API
  • a servlet throws an uncaught exception
  • the deployed application is missing classes, libraries, or configuration files
  • the private JVM runs out of memory or cannot bind properly

Because the error is generic, the first step is to find the exact exception that caused it.

Step 1: Check the Tomcat and application logs

Logs are the most reliable starting point for troubleshooting a 500 error. In most cases, the root cause is written clearly in the application output or Tomcat logs.

Where to look in Plesk

If your hosting plan includes a Java app server in Plesk, check the following:

  • Application logs for stack traces and deployment errors
  • Tomcat service logs for startup, shutdown, or binding issues
  • Web server error logs if Apache is proxying requests to the app server
  • Deployment logs after uploading or republishing a WAR file

Look for entries such as:

  • java.lang.NullPointerException
  • ClassNotFoundException
  • ServletException
  • JSP compilation failed
  • Address already in use
  • OutOfMemoryError

These messages usually point directly to the cause.

What to do with the log message

  • If you see a stack trace, identify the first application class in the trace.
  • If the error mentions a missing class, check whether the required JAR is included in WEB-INF/lib.
  • If the error mentions JSP compilation, review the JSP syntax and any imported libraries.
  • If the error happens during startup, check initialization code, database connectivity, and environment settings.

Step 2: Verify that the Java service is running

A 500 error can appear when the application server is not fully healthy, even if the site seems partially available. In a hosted Tomcat environment, confirm that your Java service is started and responding correctly.

What to check

  • the Tomcat service status in the hosting control panel
  • whether the private JVM is running
  • whether the application server restarted successfully after deployment
  • whether the service is stuck in a failed or booting state

If your hosting platform provides service controls through Plesk, use them to restart the app server cleanly. A restart can resolve temporary runtime issues, but it will not fix a broken application package or wrong configuration.

Common service-level causes

  • the service crashed during startup
  • the app server port is already in use
  • the JVM has insufficient memory
  • the process cannot read the deployed application files

If the service does not start after a restart, check the detailed log output before trying another deployment.

Step 3: Confirm the Java version matches your application

Java applications can fail with a 500 error after a Java upgrade or when the wrong runtime is selected. This is especially common when the app was built for one Java release but is running on another.

Typical compatibility problems

  • the application was compiled for an older Java version
  • a library requires a newer Java runtime
  • the app server is using a different Java version than expected
  • the application depends on APIs removed or changed in the selected runtime

If your hosting platform supports multiple Java versions in My App Server, verify that the site is attached to the correct version. Some applications run properly only on a specific major release, so a version change can trigger a 500 error immediately after deployment.

How to test this safely

  • Check which Java version the app is configured to use.
  • Compare it with the application requirements from your build file or vendor documentation.
  • Switch to a supported runtime if the current one does not match.
  • Restart the app server after changing the Java version.

If the error started after a runtime change, revert to the previous known-good version if possible.

Step 4: Review the deployment package

Many 500 errors happen because the deployed WAR file is incomplete, corrupted, or structured incorrectly. This is one of the most common issues on Java hosting platforms that allow direct upload and deploy from Plesk.

Check the WAR structure

A standard Java web application should usually contain the expected folders and files, such as:

  • WEB-INF/
  • WEB-INF/web.xml
  • WEB-INF/lib/
  • WEB-INF/classes/

If any required file is missing, the application may deploy but fail at runtime.

Look for these deployment issues

  • the WAR file was uploaded only partially
  • the archive contains nested folders with the wrong structure
  • required JAR files were omitted
  • the build process created a package with old or conflicting classes
  • the application still references files that no longer exist

Rebuilding and redeploying the application often resolves these problems. If you use a CI or local build pipeline, confirm that the package you upload is the final production build, not a test artifact.

Step 5: Check for application exceptions and missing dependencies

If the app server is running and the deployment looks correct, the error is often inside the code. Java applications commonly return a 500 error when an exception is not handled properly.

Frequent application-side causes

  • NullPointerException caused by missing data or uninitialized objects
  • ClassNotFoundException caused by missing JARs or wrong classpath
  • SQLException caused by database connection problems
  • ServletException caused by a startup or request-processing failure
  • JSP compilation errors caused by invalid syntax or missing imports

When reviewing the log, trace the error back to the first line in your code that triggered the exception. The last line is often just the visible failure; the real cause appears earlier in the stack trace.

What to verify in the application

  • database connection strings and credentials
  • environment variables used by the app
  • any recently changed configuration files
  • third-party library versions
  • file paths used by upload, cache, or log features

If the application depends on an external service, test that service separately. A database or API outage can produce a 500 error even when Tomcat itself is healthy.

Step 6: Check file permissions and ownership

Incorrect permissions can prevent Tomcat or the private JVM from reading the application files, loading configuration, or writing temporary files. That can result in a 500 error during startup or the first request.

Common permission-related symptoms

  • the app starts, but specific pages fail
  • uploads or cache directories cannot be written to
  • logs show access denied or permission denied messages
  • JSP compilation fails because Tomcat cannot create temporary files

Check that the application files and directories are readable by the web application process and writable where required. In managed hosting, permissions are usually controlled through the file manager, FTP, or the control panel.

Be careful not to set overly permissive access. The goal is to give the app the access it needs, not to expose more of the account than necessary.

Step 7: Review Apache proxy or connector settings

In many Java hosting setups, Apache serves as the front end and forwards requests to Tomcat. If Apache, the connector, or the proxy configuration is not aligned with the app server, users can see a 500 error even when the Java application itself is mostly fine.

Things to check

  • the Apache-to-Tomcat connector is enabled and healthy
  • the app is mapped to the correct context path
  • the proxy target points to the correct service and port
  • there are no duplicate or stale rewrite rules

If the error appears only on the public URL and not when testing the app server directly, the issue may be in the Apache layer rather than in the Java code.

Step 8: Check memory and startup limits

Java applications can fail with a 500 error when the JVM does not have enough memory to start or serve requests properly. This is especially relevant for applications with many libraries, large JSP pages, or heavy initialization logic.

Signs of memory issues

  • OutOfMemoryError in the logs
  • very slow startup followed by failure
  • the service restarts unexpectedly
  • random 500 errors under load

If your hosting plan allows JVM tuning, review the heap settings and other service limits. Keep the configuration realistic for shared hosting and the size of your application. A moderate increase may help, but severe memory pressure usually means the application needs optimization or a lighter deployment.

Step 9: Roll back recent changes

If the 500 error started after a change, rollback is often the fastest path to recovery. This includes code changes, dependency updates, configuration edits, and runtime changes.

Recent changes to review

  • a new WAR upload
  • a Java version switch
  • changes to web.xml
  • updated connection settings
  • new JAR files in WEB-INF/lib
  • modifications to Apache or Tomcat settings

If the app worked before the last deployment, restore the previous working version first. That helps confirm whether the issue is in the new build or in the environment.

Practical checklist for fixing a 500 error on Java hosting

Use this quick checklist when a Java site returns HTTP 500:

  • Check the application and Tomcat logs.
  • Confirm the Tomcat service or private JVM is running.
  • Verify the selected Java version.
  • Rebuild and redeploy the WAR file.
  • Check for missing classes, libraries, or resources.
  • Test database and external service connections.
  • Review file permissions and writable directories.
  • Inspect Apache proxy or connector settings.
  • Look for memory or startup limit errors.
  • Rollback the last change if the issue began recently.

How My App Server helps with troubleshooting

On a hosting platform that uses My App Server, you can manage a private Java application server through the control panel instead of relying on a separate server administration stack. That makes troubleshooting more practical for shared hosting and smaller Java applications.

Useful features typically include:

  • installing a supported Tomcat version with one click
  • choosing the Java runtime used by the app
  • starting, stopping, and restarting the service
  • deploying WAR-based applications more easily
  • running JSP and servlet applications under a separate JVM

This setup is well suited to small and medium Java applications that need control over runtime selection and deployment, without requiring complex enterprise clustering. For a 500 error, the main advantage is faster access to service control, logs, and version settings in one place.

When to contact hosting support

Contact support if you have already checked the logs and the error still cannot be isolated, or if the service itself will not start. Provide as much detail as possible so the issue can be diagnosed quickly.

Include these details

  • the exact time the error started
  • the URL or application path affected
  • the most relevant log lines or stack trace
  • the Java version in use
  • the Tomcat version or app server version
  • whether the issue started after a deployment or config change

If possible, mention whether the problem affects all pages or only one servlet, JSP, or endpoint. That helps separate an application-wide failure from a single code-path error.

FAQ

Is a 500 error always a Java problem?

No. It can also come from Apache, proxy settings, permissions, or a database outage. In a Java hosting environment, though, the cause is often inside the app or the Tomcat service.

Why does my JSP page return 500 while the homepage works?

That usually means the affected JSP page has a syntax issue, missing import, runtime exception, or a dependency problem that only appears on that page.

Can restarting Tomcat fix a 500 error?

Sometimes, but only if the issue was temporary, such as a stuck process or a transient service failure. If the app package or code is broken, a restart will not solve it permanently.

What is the most common cause after deployment?

Incorrect WAR structure, missing classes, wrong Java version, or a configuration error in the new build are among the most common causes after deployment.

How do I know whether the problem is in the app or the hosting layer?

Check the logs. If the stack trace points to your code or a missing dependency, the issue is in the app. If the service cannot start, bind, or connect, the issue may be in the app server or hosting configuration.

Conclusion

To troubleshoot a 500 error on Java hosting, start with the logs, then verify the Tomcat service, Java version, deployment package, permissions, and any recent changes. In a Plesk-based setup with My App Server, this process is usually straightforward because you can manage the Java service, runtime, and deployment from one control panel.

If the error comes from the application code, fix the exception or dependency issue and redeploy. If it comes from the hosting layer, review the service status, runtime selection, and connector settings. Working through these checks in order will usually lead you to the cause quickly and help you restore the site with minimal downtime.

  • 0 Users Found This Useful
Was this answer helpful?