A 500 Internal Server Error on Tomcat usually means the application failed to process a request, even though the web server and domain may still be reachable. On managed hosting, the issue is often caused by an app deployment problem, a Java runtime mismatch, a broken configuration file, a missing dependency, or an exception in the application code. If you are using a control panel-based Java hosting setup such as My App Server in Plesk, the fastest way to troubleshoot is to confirm whether the problem is coming from Tomcat, from the JVM, or from the application itself.
In most cases, a 500 error is not a DNS or browser problem. It is a server-side error, which means the solution is usually found in the Tomcat logs, application logs, deployment structure, or service configuration. The steps below will help you isolate the cause and restore the application as quickly as possible.
What a 500 error means on Tomcat hosting
HTTP 500 is a generic server error. In a Tomcat environment it often appears when:
- the application throws an unhandled Java exception
- a required library or class is missing
- the WAR file was deployed incorrectly or is incomplete
- the Java version does not match the application requirements
- the application cannot read its config, database, or filesystem path
- Tomcat started, but the webapp failed during startup
- the JVM ran out of memory or hit another runtime limit
If the page loads but shows a 500 error only for a specific URL or action, the issue is usually inside the application logic. If every request fails, the problem is more likely related to the deployment, runtime, or service configuration.
Check whether the error is app-specific or site-wide
Start by testing a few different pages and endpoints:
- the application home page
- a static resource, if the app serves one
- an admin or health endpoint, if available
- a simple JSP or servlet page used for testing
If only one page returns a 500, your application code or that route’s backend logic is the likely cause. If the entire app returns 500, look at deployment status, Tomcat startup logs, and JVM compatibility first.
In a hosting control panel environment, also confirm whether the service is actually running. A stopped or unhealthy private JVM can sometimes present as a generic error from the front end, especially when Apache proxies requests to Tomcat.
Review the Tomcat and application logs
Logs are the most important troubleshooting source. A 500 error is often accompanied by a stack trace, which usually points to the exact class, line, or missing resource involved.
Where to look in a Plesk-based Java hosting setup
Depending on how your Tomcat instance is configured, check:
- Tomcat application logs
- catalina.out or equivalent startup log
- access logs for the request that triggered the error
- application-specific logs written by your app
- control panel service status and event logs
If you are using My App Server, use the service controls in Plesk to confirm the Java service is running normally, then open the logs for the app server instance. Look for messages such as:
- ClassNotFoundException
- NoClassDefFoundError
- ServletException
- NullPointerException
- SQLException
- OutOfMemoryError
- Port already in use
These messages typically indicate the next step to take. For example, a database error means the app is reaching the servlet layer but failing when it tries to query a backend system.
Confirm that Tomcat is running correctly
Before focusing on the application, make sure the service itself is healthy. In managed hosting, Tomcat may be installed as a private JVM under your account, with service control exposed through the panel. Use the service control options to:
- check whether the service is started
- restart the service cleanly
- verify that the correct Java version is selected
- confirm that the app server instance is bound to the expected application path
If the service fails to start or restarts immediately, investigate the startup logs. A startup failure often means one of the following:
- the configured Java version is incompatible
- the server port is already in use
- the deployment directory is malformed
- the JVM options are invalid
- the web application throws an exception during initialization
If the service starts but the site still returns 500, the issue is more likely at the application layer than in the service itself.
Check the Java version and runtime compatibility
One of the most common causes of 500 errors on Tomcat hosting is a Java version mismatch. A web application compiled or tested on one Java release may fail on another if it uses deprecated APIs, newer language features, or libraries that expect a specific runtime.
In a My App Server setup, one advantage is that you can choose from available Java/Tomcat versions or upload and configure a custom version where supported. That flexibility is useful, but it also means you should verify the application requirements carefully.
What to verify
- the Java version required by the application
- the Tomcat major version required by the WAR
- whether the app expects JSP, Servlet, or Jakarta package namespaces
- library compatibility with the selected JVM
If the application was built for older javax-based Tomcat and is deployed on a newer Jakarta-based stack, class and package errors can cause 500 responses. Check the build documentation or release notes from the application vendor, then match the runtime accordingly.
Inspect the WAR deployment and application structure
An incomplete or incorrect deployment is a frequent reason for broken applications on Tomcat. If you uploaded a WAR file manually or replaced files in the webroot, confirm the application is laid out in a valid Tomcat format.
Deployment checks
- the WAR file is complete and not corrupted
- the deployment finished successfully
- the app files are in the correct directory
- the context path matches the URL you are testing
- there are no leftover files from an older deployment
If you recently updated the app, test whether the previous version still works. If it does, the new release may have introduced a code or packaging problem. Rebuild the application and redeploy it cleanly, rather than copying individual files over the top of an existing installation.
When using a hosted control panel, it is also helpful to remove stale deployment artifacts before uploading a fresh build. Old compiled classes, cached JSP files, or partial unpacked directories can keep Tomcat in a broken state even after the source package looks correct.
Check for missing dependencies and classpath issues
Tomcat 500 errors often come from missing JAR files or classpath problems. If the app can start but fails on certain requests, a class may not be available when the code tries to load it.
Typical dependency problems
- a third-party JAR was not included in WEB-INF/lib
- the wrong version of a library is bundled
- the app expects a class provided by the container, but it is missing
- duplicate libraries cause conflicts
- the app uses a class from an older framework version
Look in the logs for exceptions such as ClassNotFoundException and NoClassDefFoundError. These usually point directly to the missing dependency. If the error appears after an update, compare the current build with the previous working release and restore any removed libraries that are still required.
Review database connectivity and backend services
Many Tomcat applications return 500 when they cannot reach a database or another internal service. This is especially common for JSP and servlet applications that perform dynamic content generation on every request.
What to check
- database hostname, port, username, and password
- JDBC driver presence and version
- connection pool settings
- firewall or network access rules
- timeouts to remote APIs or internal services
If the logs show SQL exceptions, test the database connection separately. If the database was recently changed, confirm the credentials stored in the application configuration are still valid. A successful Tomcat service restart does not guarantee the app can reach its data source.
For applications that rely on external APIs, a 500 may occur when the upstream service is unavailable or slow. In that case, adding better error handling or timeout settings may be necessary. On the hosting side, verify that your application has enough time to complete the request without hitting timeout thresholds in the proxy or Tomcat layer.
Check configuration files and environment settings
Configuration issues are another common source of server errors. A small typo in a property file can cause the app to fail during startup or request handling.
Examples of configuration problems
- incorrect file paths
- missing environment variables
- invalid XML or properties syntax
- wrong context parameters
- broken permissions on uploaded config files
Look for application-specific configuration files, then confirm that the values match the current hosting environment. Pay special attention to path separators, file encodings, and relative vs absolute paths. If the application worked locally but fails on hosting, the issue is often a path or permissions difference.
In a control panel environment, also check whether the app expects a working directory or data directory that is not yet created. If so, create it with the correct ownership and permissions before retesting.
Verify file and directory permissions
Tomcat needs read access to application files and, in some cases, write access to temp, cache, upload, or log directories. If permissions are too strict, the app may throw a 500 when it tries to read templates, store files, or write session data.
Permission checklist
- webapp files are readable by the Tomcat process
- upload directories are writable when required
- temp and cache directories exist
- log directories are writable if the app creates its own logs
- no parent directory blocks access to resources
If the error started after a file upload or migration, compare the ownership and permissions of the new files with the previous working version. Incorrect permission changes can be enough to break a JSP or servlet app even when the code itself is fine.
Look for JVM memory or resource limits
A 500 error can also appear when the JVM runs out of memory or when the application uses more resources than the hosting service allows. In shared Java hosting, limits are designed to keep the environment stable, so a memory-heavy application may need tuning rather than a code rewrite.
Common signs include:
- OutOfMemoryError in the logs
- the service becomes slow before failing
- requests time out during heavier traffic
- Tomcat restarts under load
If you see memory errors, review the JVM options provided by your app server service. Reduce excessive cache use, lower the application’s memory footprint, or optimise the code path that is consuming too much heap. For hosted Tomcat services, it is important to stay within the platform’s limits and configure the app to fit the allocated resources.
Check reverse proxy or Apache integration if used
In some hosting setups, Apache handles the public web layer and proxies requests to Tomcat. If the proxy configuration is incorrect, users may see 500 errors even if the Java service is partially working.
Confirm that:
- the proxy target points to the correct Tomcat instance
- the configured context path is correct
- Apache and Tomcat agree on the route mapping
- SSL and redirect rules are not looping
If only requests coming through the public domain fail, but local or internal checks work, the issue may be in the Apache-to-Tomcat handoff rather than in the Java app itself.
Practical step-by-step troubleshooting flow
If you want a fast way to isolate the cause, use this order:
- Confirm whether the service is running in the control panel.
- Open the latest Tomcat and application logs.
- Reproduce the error and note the exact timestamp.
- Look for stack traces, missing classes, SQL errors, or memory issues.
- Verify the Java version and Tomcat version match the app’s requirements.
- Check deployment structure, WAR integrity, and context path.
- Review database credentials and backend connectivity.
- Inspect permissions for config, temp, and upload directories.
- Restart the service after changes and retest.
This method works well because it separates service issues from app issues and avoids random changes that can make troubleshooting harder.
How My App Server helps with Tomcat 500 troubleshooting
If you are using My App Server in Plesk, you have a practical advantage for Tomcat troubleshooting: the private JVM and Tomcat service are managed from the control panel, which makes it easier to inspect the application server state, switch versions, and restart cleanly without manual server administration.
That is especially useful when troubleshooting public-facing 500 errors on Java hosting, JSP hosting, or servlet hosting. Instead of guessing, you can:
- check the service status in the panel
- restart the app server after fixing configuration
- choose a different supported Java version if needed
- deploy a WAR package more cleanly
- test whether the error persists after a fresh start
For small and medium Java applications, this workflow is often enough to resolve deployment and runtime issues quickly without needing a separate application server stack.
Common fixes that resolve 500 errors on Tomcat
- restart Tomcat after correcting a bad deployment
- switch to the Java version required by the application
- rebuild and redeploy the WAR file cleanly
- restore missing libraries in WEB-INF/lib
- fix database credentials or JDBC driver issues
- correct file permissions on config and upload folders
- remove invalid JVM options from the service configuration
- clear stale temp and cache files if the app supports it
If the application worked before and suddenly returns 500, the most likely causes are a recent code change, a configuration change, a version mismatch, or an expired backend dependency.
When to restore a previous working version
If the error started immediately after an update, rollback is often the fastest recovery option. Restore the last known good release if:
- the app worked before the deployment
- logs show new exceptions after the update
- a library or framework upgrade changed the runtime behavior
- you need service restoration before deeper debugging
Once the site is stable again, compare the old and new builds carefully. Focus on changed dependencies, config files, database migrations, and build settings. This usually reveals the root cause faster than testing every possible component from scratch.
FAQ
Why does Tomcat show 500 instead of a more specific error?
Because 500 is a general server-side failure. Tomcat often returns it when the application throws an unhandled exception, fails to initialize, or cannot complete the request properly. The detailed reason is usually in the logs.
Can a 500 error be caused by the browser?
Usually not. A browser issue may affect how the page is displayed, but a 500 error means the server failed while processing the request.
What should I check first on managed Tomcat hosting?
Start with the service status and the logs. Then verify the Java version, deployment, and configuration files. On a control panel-based setup, those checks usually identify the problem faster than editing code blindly.
Can the wrong Java version cause a 500 error?
Yes. If the application was built for a different Java release or depends on incompatible libraries, Tomcat may fail during startup or while handling requests.
Why does the app work locally but not on hosting?
Common reasons include different Java/Tomcat versions, missing libraries, stricter file permissions, database access restrictions, or configuration differences between environments.
Should I clear Tomcat cache or temp files?
If the app uses stale compiled JSPs, cached classes, or broken temporary files, clearing them can help. Do this carefully and only after backing up the current deployment if possible.
When should I contact hosting support?
Contact support if the service will not start, logs are unavailable, the control panel shows a platform-side problem, or you need help checking service configuration and limits. Include the exact error time and any stack trace from the logs.
Conclusion
To troubleshoot a 500 error on Tomcat hosting, focus on the logs first, then verify service health, Java version, deployment structure, dependencies, database connectivity, and file permissions. In a Plesk-based Java hosting environment with My App Server, you can usually narrow the issue down quickly by checking the private Tomcat service, comparing the runtime version with the application requirements, and redeploying the WAR cleanly.
If the error only affects one page, the root cause is usually inside the application code. If the whole site fails, start with the service, runtime, and deployment. Following that order will help you resolve most Tomcat 500 errors efficiently without unnecessary changes.