Startup errors in a hosted Java app are usually caused by a small number of predictable issues: the wrong Java version, a broken Tomcat configuration, missing environment variables, a bad WAR deployment, or a service that did not start cleanly after a restart. In a managed hosting environment with Plesk and a Java extension such as My App Server, the problem is often not the application code itself, but how the app server, JVM, and deployment package are connected.
If your Java application fails to start, the fastest way to narrow it down is to check the service status, review the startup logs, confirm the selected Java/Tomcat version, and verify that the application has been deployed in the expected format. This article explains the most common causes of startup errors in hosted Java apps in the UK hosting context and gives practical steps to fix them.
What startup errors usually mean in a hosted Java app
A startup error means that the application server, such as Apache Tomcat, was unable to initialize the app successfully. In a hosting platform, this can happen during service start, after a deployment, or when the JVM loads the application for the first time. The error may appear as a blank page, a 500 error, a service marked as stopped in Plesk, or a message in the application log such as SEVERE, ClassNotFoundException, UnsupportedClassVersionError, or Port already in use.
For hosted Java, JSP, and servlet applications, the startup process depends on several layers working together:
- the selected Java runtime
- the Tomcat instance or private JVM
- the deployed WAR or application directory
- the app server configuration files
- file permissions and ownership
- resource limits within the hosting account
If one of these layers is incorrect, the app may fail before it reaches the point where the browser can connect to it.
Most common causes of startup errors
1. Wrong Java version selected
One of the most frequent causes is a mismatch between the Java version your application expects and the version configured in the control panel. A project compiled for a newer Java release may not run on an older runtime. The opposite can also cause issues if the app depends on libraries or syntax no longer supported in the selected setup.
Typical symptoms include:
UnsupportedClassVersionErrorClassNotFoundExceptionduring startup- Tomcat starts, but the web application fails to load
In My App Server, check whether the application is using the intended Java version and whether the version is one of the available preinstalled options or a custom setup you uploaded manually.
2. Tomcat or app server configuration error
Startup may fail because of an invalid Tomcat setting, a malformed server.xml, a broken context configuration, or incorrect connector settings. If the hosting platform allows separate control of the app server, a small misconfiguration can stop the service from initializing.
Common examples include:
- invalid port assignments
- wrong path to the application directory
- bad XML syntax in configuration files
- duplicate connector definitions
In a managed hosting setup, it is usually better to keep custom changes minimal unless you specifically need them. If the app worked before a manual change, revert the last configuration edit first.
3. The WAR file is incomplete or corrupted
If you deploy a WAR file and the archive is damaged, missing classes, or built incorrectly, Tomcat may fail while unpacking or initializing the application. This is common after an interrupted upload or when the build pipeline produced a package that does not match the expected structure.
Look for signs such as:
- deployment stops partway through
- the app directory is created but the application does not respond
- log files mention missing resources, libraries, or descriptors
Rebuild the package and redeploy it. If possible, test the same WAR locally before uploading it again.
4. Missing dependencies or libraries
Java applications often rely on external JAR files or framework dependencies. If a required library is absent from WEB-INF/lib or the classpath is not set correctly, the app may fail immediately on startup. This is especially common when moving from local development to hosted deployment.
Examples include:
- Spring, Hibernate, JDBC, or logging libraries missing from the bundle
- a custom class not included in the deployment package
- an external driver not available on the server
Check the first error in the log, not only the final exception. The first missing class usually points to the real cause.
5. Database connection failure during startup
Some applications try to connect to a database as part of initialization. If the database host, username, password, port, or JDBC URL is wrong, the app may stop before it becomes available in the browser.
Typical startup failures include:
- authentication errors
- connection timeout
- driver not found
- invalid JDBC URL format
This is common when moving between environments or after updating database credentials in the control panel but not in the application properties. Verify the JDBC settings and test the database connection separately if possible.
6. Port conflict or service already in use
If the app server tries to bind to a port that is already occupied, startup will fail. This can happen after an unclean shutdown or if another service uses the same port. In shared hosting with private JVM or Tomcat management, each app server instance must have a unique and valid port layout.
Look for messages such as:
Address already in useConnector failed to startPort ... is already in use
Review the service configuration and confirm that no conflicting process is using the same port.
7. File permission or ownership issue
If Tomcat cannot read the application files or write to its working directories, startup can fail or the app may start only partially. This often happens after uploading files manually, restoring backups, or replacing directories without preserving correct permissions.
Check that the application can access:
- the WAR file or unpacked app directory
- temporary and work directories
- log directories
- uploaded configuration files
If your hosting platform provides a file manager or Plesk tools, use them to verify ownership and permissions. Avoid overly permissive settings unless they are specifically required.
8. Memory limit reached during startup
Some apps need more heap memory than the default JVM allocation allows. Large frameworks, verbose XML configuration, or heavy initialization logic may cause startup to fail with an OutOfMemoryError or related JVM message.
Symptoms may include:
- the service starts and then stops immediately
- long startup time followed by failure
- memory-related entries in the log
In a shared hosting plan, memory settings are usually bounded by the service limits. Check the available JVM settings and reduce application overhead where possible.
9. Application code throws an exception during initialization
Sometimes the hosting platform is functioning correctly, but the application itself fails when it loads a servlet, listener, or framework component. This can happen if startup code assumes a value exists, calls a remote service, or reads a configuration file that is missing.
Common causes include:
- invalid properties file
- missing environment value
- unsafe initialization logic
- API incompatibility after an update
In these cases, the log will usually show a stack trace from your application package, not just Tomcat internals.
10. Unsupported custom server changes
Hosted Java environments are often stable when used with standard Tomcat deployment patterns. Startup problems appear when a custom app server setup is changed too aggressively, such as manual edits to core configuration files, custom classloading changes, or nonstandard startup scripts.
If you use a custom Tomcat or private JVM setup through My App Server, keep a record of each change. When something breaks, roll back one change at a time instead of editing multiple settings at once.
How to troubleshoot startup errors step by step
Step 1: Check whether the service is actually running
Open the hosting control panel and verify the status of the Java service. In a Plesk-based setup, the service control area should show whether the app server is running, stopped, or failed to start. If the service is stopped, try a controlled restart and note whether it fails immediately or after a delay.
If restart fails, the service status alone is not enough. You need the log output to determine why.
Step 2: Review the startup and application logs
The first useful error message is usually in the service log or the Tomcat log. Look for:
- the first
SEVEREmessage - stack traces near startup time
- class loading errors
- database connection failures
- port binding errors
Do not focus only on the final line. Often the final message is a consequence, while the real cause appears several lines earlier.
Step 3: Confirm the Java version and Tomcat version
Make sure the application is being launched with the correct Java release and that the Tomcat version is compatible with the app. If you recently switched versions in My App Server, test the application again after the change. If you uploaded a custom version, confirm that it is configured and started correctly.
Version mismatches are especially common when moving an older JSP or servlet app to a newer runtime, or when compiling with a modern JDK and deploying to an older one.
Step 4: Validate the deployment package
Check that the application was uploaded completely and that the WAR file is valid. If possible, compare the deployed files with your local build output. Make sure the app includes all required classes, descriptors, resources, and libraries.
Useful checks include:
- the WAR opens correctly on your computer
WEB-INF/web.xmlis present if the app requires it- all JAR dependencies are included
- the deploy path matches the expected context root
Step 5: Test database access separately
If your app depends on a database, verify that credentials work and that the database host is reachable from the application environment. A valid database account is not enough if the JDBC driver is missing or the connection string is incorrect.
For hosted Java apps, a startup failure caused by database access usually appears in the log as a connection exception early in the initialization sequence.
Step 6: Check permissions and writable paths
Make sure the app can write to temporary directories, upload folders, cache folders, and log paths. A Java app that cannot create temp files may fail during startup even if the code itself is otherwise correct.
If you recently restored a backup or moved the application, check whether file ownership changed during the process.
Step 7: Reduce custom changes and restart cleanly
If the application previously worked, undo the latest changes first. This includes edits to configuration files, new dependencies, version changes, and altered environment settings. Restart the service after each rollback so you can identify the exact trigger.
Clean restarts are useful when Tomcat has stale state in work directories or when a failed deployment left behind partial files.
What to check in My App Server on Plesk
In a hosted Java environment with My App Server, the control panel gives you several useful points to check before escalating the issue:
- service status and start/stop controls
- selected Java version
- Tomcat or custom app server instance selection
- deployment status of the WAR or application directory
- available log files for troubleshooting
- service limits relevant to memory and process usage
If you are using one of the ready-to-install Java/Tomcat versions, confirm that the deployment matches the chosen runtime. If you are using a custom app server version, make sure the uploaded files and configuration are complete and consistent.
Examples of startup errors and likely causes
Example 1: UnsupportedClassVersionError
This usually means the app was compiled with a newer Java version than the runtime on the server. Recompile for the supported version or switch the service to a compatible Java runtime.
Example 2: Port already in use
The app server cannot bind to the configured port. Check for another service using the port, or adjust the connector settings if your hosting platform allows it.
Example 3: Context failed to initialize
Usually caused by a missing dependency, bad configuration value, or a failing database connection during startup. Review the stack trace for the first real exception.
Example 4: Application deploys but does not open
This may point to an internal application error, a wrong context path, or a failed initialization listener. Confirm that the WAR was deployed to the correct location and that the logs show no startup exception.
How to prevent startup errors in future deployments
You can reduce startup problems by following a simple deployment checklist:
- build the app against the Java version supported by the hosting service
- deploy a clean WAR, not a partially copied directory
- include all required libraries in the package
- avoid unnecessary manual edits to Tomcat configuration
- test database credentials before deployment
- keep a copy of working configuration files
- restart the service after major changes
If your app is small to medium sized and runs on a private JVM or Tomcat instance in a shared hosting account, keeping the deployment process simple is often the best way to avoid startup failures.
When to contact support
Contact support if you have already checked the logs, Java version, deployment package, and service status, but the application still fails to start. Useful information to include is:
- the exact error message from the log
- the time of the failed startup
- the Java version and Tomcat version in use
- what changed before the error appeared
- whether the issue occurs after every restart or only after deployment
Providing this detail helps isolate whether the issue is related to the application code, the deployment package, the service configuration, or an account-level limit.
FAQ
Why does my Java app start locally but fail on hosting?
Local and hosted environments often use different Java versions, different Tomcat versions, and different filesystem permissions. A missing library or database setting can also remain hidden until deployment.
Can a bad WAR file stop Tomcat from starting?
Yes. If the archive is corrupted, incomplete, or built incorrectly, Tomcat may fail while unpacking or initializing the application.
Is a startup error always caused by the app itself?
No. The cause may be the JVM version, Tomcat configuration, port conflict, file permissions, or hosting limits. The logs usually show which layer failed first.
What is the first thing to check after a failed deployment?
Check the logs, then confirm the selected Java version and whether the WAR uploaded correctly. These three checks solve many startup issues.
Can I run a private JVM or Tomcat instance for my app?
Yes, in a setup like My App Server you can manage a private JVM or Apache Tomcat instance within the hosting account, which is useful for Java, JSP, servlet, and WAR-based applications.
Conclusion
Startup errors in a hosted Java app are usually caused by version mismatches, Tomcat configuration problems, broken deployments, missing dependencies, database connection failures, permission issues, or resource limits. In a Plesk-managed hosting environment with My App Server, the quickest path to resolution is to check service status, read the logs, verify the Java and Tomcat versions, and validate the deployment package.
When you treat startup failures as a step-by-step problem rather than a single server error, most issues become easy to isolate and fix. For small and medium Java applications, a clean deployment process and a consistent control panel setup are often enough to keep the service running reliably.