If your Tomcat-based website or Java application is returning a 500 error, the problem is usually inside the application, the Tomcat runtime, or the way the app is deployed in your hosting control panel. A 500 Internal Server Error means the server could not complete the request, but it does not always mean the same thing. On hosted Tomcat environments, the fastest way to resolve it is to check the application logs, verify the Java and Tomcat setup, and confirm that the deployed files, permissions, and context configuration are correct.
In a managed hosting environment with Plesk and a Java hosting extension such as My App Server, you can often troubleshoot the issue without needing root access. You can review the Tomcat service status, restart the service, confirm the selected Java version, and check whether your WAR or application files were deployed correctly. This article explains the most common causes of 500 errors on Tomcat hosting in the UK and how to fix them step by step.
What a 500 error means on Tomcat hosting
An HTTP 500 error is a general server-side error. In a Tomcat environment, it commonly appears when:
- the Java application throws an unhandled exception
- Tomcat cannot start the web application
- a class, library, or resource is missing
- the deployed app has invalid configuration
- file permissions prevent Tomcat from reading or writing files
- the app is using a Java version it is not compatible with
- the JVM or Tomcat service has stopped responding
Because 500 errors are broad, the actual fix depends on what the logs show. In most cases, the error is not caused by the hosting platform itself, but by an issue in the deployed application or its runtime settings.
Check the Tomcat and application logs first
The logs are the most useful source of information when a Tomcat app returns a 500 error. They usually tell you exactly which class, configuration file, or dependency is failing.
What to look for in the logs
- Stack traces showing the Java exception type and line number
- ClassNotFoundException or NoClassDefFoundError for missing libraries
- NullPointerException caused by application logic or missing settings
- OutOfMemoryError if the JVM memory is too low
- Port already in use errors if another service is conflicting
- Deployment errors during startup or context loading
Where to find logs in a Plesk-based Tomcat setup
In a hosted environment, log access is often available from your control panel or the application directory. Depending on your configuration, you may find logs for:
- Tomcat startup and shutdown events
- your specific web application
- Apache reverse proxy or web server access and error logs
- Java application output and stack traces
If you are using a Java hosting solution with a private JVM, the logs should help identify whether the issue is inside the app or in the Tomcat service itself.
Restart the Tomcat service from the control panel
Sometimes a 500 error appears after a failed deployment, a partial restart, or a temporary JVM issue. A clean restart can clear locked files, stale connections, and temporary startup problems.
When a restart helps
- the app worked before and suddenly started failing
- you uploaded a new WAR file or changed configuration
- Tomcat appears active, but the app is not responding correctly
- the logs show a temporary startup problem
Best practice before restarting
Before restarting the service, save any recent changes you made to the application, deployment files, or context configuration. If the issue started immediately after a deployment, keep a copy of the previous working version so you can roll back if needed.
Verify that the Java version matches your application
One of the most common causes of a 500 error on Tomcat hosting is a Java version mismatch. A web application compiled for one version of Java may fail when deployed with another version, especially if it uses newer language features or outdated libraries.
Things to confirm
- the application supports the selected Java version
- the Tomcat version is compatible with that Java runtime
- your build tools and libraries were compiled for the same Java level
- the app does not rely on deprecated APIs removed in newer Java releases
If your hosting plan allows you to choose between multiple Java versions, test the app with the version recommended by the developer or framework. For example, an older application may require Java 8, while a newer one may need Java 11 or later. If you recently changed the Java version and the 500 error started after that, revert to the previous working version and test again.
Check whether the WAR or application files were deployed correctly
Tomcat applications often fail with a 500 error when the deployment is incomplete or the archive is damaged. This can happen if the WAR file was uploaded incorrectly, extracted partially, or replaced while the application was still running.
Common deployment problems
- corrupted WAR archive
- missing WEB-INF classes or libraries
- incorrect directory structure
- files uploaded to the wrong location
- old files left behind after an update
How to test deployment issues
- Remove the current deployment if it is broken.
- Upload a fresh copy of the WAR or application files.
- Let Tomcat redeploy the application cleanly.
- Check the logs during startup for any missing resource or class errors.
- Open the site again and verify whether the 500 error is gone.
If your app is deployed from extracted files rather than a WAR, confirm that the structure is correct and that all files required by the application are present.
Review file permissions and ownership
File permission issues can trigger a 500 error if Tomcat cannot read application files, write temporary data, or access log directories. This is especially important for applications that create uploads, cache files, session data, or generated content.
Check these areas
- the web app directory and all subdirectories
- configuration files such as XML or properties files
- temporary folders used by the JVM or application
- directories used for uploads, caches, or logs
Permissions should allow the Tomcat service user to read the application and write only where necessary. Overly strict permissions can block startup, while overly open permissions can create security problems. If you are unsure which ownership model your hosting account uses, use the control panel or hosting documentation to verify the expected file access settings.
Look for missing libraries or dependency conflicts
Java applications often depend on external JAR files. If one of those libraries is missing, duplicated, or incompatible, Tomcat may load the app but fail when a request is made, returning a 500 error.
Typical dependency-related symptoms
- application starts, but specific pages return 500
- the logs mention a missing class or method
- a library works in development but not in production
- the application fails after a framework upgrade
To troubleshoot this, compare the deployed libraries with the application’s documented requirements. Check whether the same JAR appears in more than one location or whether an older version is overriding the correct one. If the application uses frameworks such as Spring, Hibernate, or other Java web libraries, make sure their runtime dependencies are complete.
Check the application configuration files
A 500 error can also happen when the app’s own settings are incorrect. This is common with database connections, environment-specific properties, and context parameters loaded at startup.
Configuration files that often cause problems
- XML configuration files
- properties files
- database connection settings
- environment variables and secrets
- framework-specific config files
What to verify
- file paths are correct
- all required values are present
- there are no syntax errors in XML or properties files
- database host, username, and password are accurate
- the app can reach its backend services
If the error started after a configuration edit, compare the current file with a known working version. Even a small typo can prevent the application from starting properly.
Test whether the error is caused by the application code
Sometimes the hosting platform and Tomcat service are working correctly, but the application itself is throwing an exception on a specific page or action. In this case, the 500 error may be limited to one route, form, or API call.
Examples of app-level causes
- a database query is failing
- the code expects data that is missing
- a form submission sends invalid values
- an external API request times out
- a template or JSP file has a syntax problem
If only one page fails, while the rest of the application works, the issue is likely in the code for that page or endpoint. Review the stack trace carefully and test the request with simpler input. If possible, reproduce the problem in a staging copy before changing the live app.
Check database connectivity if the app uses a database
Many Java and Tomcat applications return a 500 error when they cannot connect to the database. The failure may happen at startup or only when a page attempts to load data.
What to confirm
- the database server is reachable from the hosting environment
- the database name, user, and password are correct
- the JDBC driver is installed and compatible
- connection pool settings are valid
- the database account has the required permissions
A bad connection string, expired password, or missing JDBC driver can all cause a 500 error. If the logs mention SQL exceptions or connection failures, focus on the database layer before changing Tomcat settings.
Confirm that Apache and Tomcat are working together correctly
In many hosting setups, Apache handles the public web traffic and forwards Java requests to Tomcat. If the proxy or connector is misconfigured, the site may display a 500 error even if the application itself is fine.
Possible integration issues
- incorrect proxy pass or connector settings
- Tomcat not listening on the expected port
- virtual host routing problems
- conflicting rewrite rules
- the Apache side cannot reach the backend service
If the application loads through direct Tomcat access but fails through the public domain, the issue may be in the Apache-to-Tomcat path. In a managed Plesk environment, the hosting platform usually handles this integration, but app-specific configuration can still affect the result.
Use My App Server controls for basic recovery steps
If your hosting account includes My App Server, you can usually handle common recovery actions from the control panel without needing to access the server directly. This is useful for Tomcat hosting, JSP hosting, servlet hosting, and small to medium Java applications that need a private JVM.
Helpful control panel checks
- verify the service status
- restart the app server after deployment
- confirm the selected Java version
- review the deployed application path
- check whether a custom app server or Tomcat version is in use
If you have installed a ready-made Tomcat version with a single button, make sure the application was deployed to the correct instance. If you uploaded a custom Tomcat setup, verify that its paths, memory settings, and startup files match the application’s requirements.
Step-by-step troubleshooting checklist
- Open the application logs and identify the exact exception.
- Restart the Tomcat service from the control panel.
- Confirm that the selected Java version is supported by the app.
- Check whether the WAR or extracted files were deployed cleanly.
- Review file permissions and writable directories.
- Verify configuration files, database settings, and external endpoints.
- Test whether the issue affects one page or the whole site.
- Compare with a previously working deployment if you have one.
- If needed, redeploy the application from a fresh package.
Common log messages and what they usually mean
ClassNotFoundException
A required class cannot be found. Check the application libraries and deployment package.
NoClassDefFoundError
A class was available at compile time but not at runtime. This often means a missing or incompatible JAR.
NullPointerException
The application tried to use a value that was not initialized. Review the code path and the request data.
OutOfMemoryError
The JVM ran out of memory. The app may need more memory or a lighter workload.
SQLException
The database connection or query failed. Check credentials, permissions, and database availability.
SEVERE: Error starting endpoint
Tomcat could not start a connector or port. Another process may already be using the port, or the configuration may be invalid.
When to redeploy, roll back, or ask for support
If the 500 error started immediately after an update, the quickest fix may be to roll back to the previous working version. If a fresh redeploy solves the problem, the original package was likely damaged or incomplete.
Contact hosting support if:
- the logs show a platform-level issue you cannot change from the control panel
- the Tomcat service fails to start repeatedly
- you cannot access the relevant logs
- the problem continues after a clean redeploy and configuration review
- you suspect a control panel or service integration problem rather than an application bug
When you contact support, include the time of the error, the affected URL, recent changes, the Java version in use, and the relevant log entries. This usually speeds up diagnosis significantly.
FAQ
Is a 500 error on Tomcat usually caused by the hosting platform?
Not usually. In most cases, the cause is inside the application, its dependencies, or its configuration. The hosting platform is more likely to reveal the issue than cause it.
Why does the application work locally but fail on hosted Tomcat?
The hosted environment may use a different Java version, different file permissions, or a different set of libraries. Local and hosted settings are often not identical.
Can changing the Java version fix a 500 error?
Yes, if the app is not compatible with the currently selected Java runtime. Always test with the version recommended by the application developer.
What if only one page returns 500?
That usually points to application code, a database query, or a bad request parameter on that specific page rather than a full Tomcat failure.
Should I reinstall Tomcat if I get a 500 error?
Usually no. A reinstall is rarely the first step. It is better to check logs, deployment files, Java version, permissions, and configuration before making bigger changes.
Can a bad WAR file cause this error?
Yes. A corrupted or incomplete WAR is a common reason for startup failures and runtime 500 errors in Tomcat hosting.
Conclusion
A 500 error on Tomcat hosting is a sign that something failed on the server side, but the root cause is often narrow and identifiable. Start with the logs, then verify the Java version, deployment package, permissions, database settings, and Tomcat service status. In a Plesk-based hosting environment with My App Server, you can resolve many issues from the control panel by restarting the service, checking the selected Java runtime, and redeploying the application cleanly.
For Tomcat and Java applications, the most effective approach is methodical troubleshooting: confirm the runtime, inspect the logs, isolate the failing component, and then test one change at a time. That usually gets a broken app back online much faster than guessing at the cause.