Managing a Tomcat hosting environment is usually straightforward when your Java runtime, application server, and deployment process are all handled from one place. In a hosted setup with Plesk and a Java extension such as My App Server, you can review logs, restart the service, and deploy updates without needing full server administration access. This is especially useful for WAR-based Java applications, JSP sites, and small servlet apps that need a private JVM or an isolated Tomcat instance.
This guide explains how to work with Tomcat logs, when to restart the service, and how to apply application updates safely in a managed hosting account. It is written for users who want practical steps rather than server-level theory, and it assumes a Tomcat or JSP hosting setup controlled from your hosting panel.
Where Tomcat logs are usually found
In a hosting platform that provides Tomcat through a control panel, logs are typically stored in locations linked to your application server instance rather than in a global system directory. Depending on the setup, you may see logs in the application directory, in a dedicated service folder, or inside the Plesk-managed user space. The exact path can vary by Java version, Tomcat version, and whether you installed a ready-made service or uploaded a custom app server.
Common log types include:
- Tomcat access logs for requests made to your application.
- Catalina or service logs for startup, shutdown, and runtime events.
- Application logs written by your Java app, framework, or logging library.
- Error logs for deployment issues, stack traces, and configuration problems.
If your hosting platform uses a control panel extension such as My App Server, the log location is often displayed in the service details or in the application management area. That makes it easier to check problems without SSH access or manual server configuration.
How to inspect Tomcat logs from the control panel
The easiest way to troubleshoot Tomcat hosting is to start in the panel. If your hosting provider has enabled log access in the service management area, follow these steps:
- Sign in to your hosting control panel.
- Open the Java or application server section, such as My App Server.
- Select the relevant Tomcat service or application instance.
- Look for a Logs, Service logs, or Application logs tab.
- Open the most recent entries and check for startup errors, missing files, port conflicts, or deployment warnings.
When reading logs, focus first on the time when you restarted the service or uploaded a new WAR file. The most useful lines are usually the first error after startup and the first stack trace related to your application. If the application starts but returns a blank page or 500 error, the logs often show whether the issue comes from a missing class, a bad database connection, a configuration file problem, or an incompatible Java version.
What to look for in startup logs
- Java version mismatch between the application and the server.
- Port conflicts if the service cannot bind to its configured port.
- Missing context path or failed WAR expansion.
- Permission issues for temp, work, or upload directories.
- Database connection failures during application initialization.
Checking logs through file manager or FTP
If the panel does not show the log file directly, you can often access it with File Manager or FTP. This is common in shared hosting environments where the account is limited to user-level access. Look for directories related to your app server instance, deployed application, or the Tomcat installation folder provided by the hosting platform.
When using File Manager or FTP, download the relevant log file and open it in a text editor that can handle large files. For active applications, log files can grow quickly, so it helps to review only the latest section. If your issue is recurring, save a copy before the next restart so you can compare changes.
Useful log-review habits:
- Check the latest timestamps first.
- Search for SEVERE, ERROR, Exception, and Failed.
- Compare the current log with the previous deployment.
- Keep a copy of the log before and after each update.
How to restart Tomcat safely
Restarting Tomcat is a normal part of service management after a deployment, configuration change, or troubleshooting session. In a managed hosting platform, the restart action is usually available in the service control area. Because Tomcat runs as a private service under your account, the restart typically affects only that application server instance, not the entire hosting platform.
Before restarting, make sure you understand why you are doing it. A restart is appropriate when you have:
- Uploaded a new WAR file.
- Changed application configuration files.
- Modified Java options or environment variables.
- Applied a Tomcat version or Java version update.
- Need to clear an application state issue after an error.
Restart steps in a managed Tomcat hosting setup
- Open the control panel and go to the Java hosting or My App Server section.
- Select the active Tomcat service.
- Check that the application status is healthy before restarting.
- Use the Restart or Stop and Start option.
- Wait for the service to report that it is running again.
- Refresh the application and confirm that it loads correctly.
If the restart takes longer than expected, review the logs immediately. A Tomcat service that fails to come back up often points to a deployment error, a corrupted WAR, a configuration problem, or a Java incompatibility. In a hosted environment, the logs are the fastest way to determine whether the service is starting but your application is failing, or whether the entire Tomcat process is not launching at all.
When you should not restart immediately
It is tempting to restart as the first response to any issue, but that is not always the best approach. If the problem is caused by a misconfigured property, an invalid database URL, or a broken JSP file, a restart alone will not fix it. In some cases, restarting too often can make diagnosis harder because it overwrites the most useful log entries.
Try to avoid an immediate restart when:
- The logs already show a clear configuration error.
- You still need to capture the exact failure message.
- The problem happened after a code change and should be reviewed first.
- You have not confirmed whether the issue is in Tomcat or in the application itself.
A better approach is to review the logs, identify the relevant error, correct the root cause, and then restart once. This is especially important on Tomcat hosting plans intended for small and medium applications, where clean deployment and clear service control matter more than complex server-side automation.
Updating a Java application on Tomcat hosting
Application updates in Tomcat hosting are usually handled by replacing the deployed WAR file, redeploying application resources, or updating files in the web application directory. In a control panel-based hosting service, the update process is often designed to be simple so you can maintain your app without managing the whole server stack.
For WAR deployments, the typical update flow is:
- Build the new application version locally.
- Confirm that it targets the correct Java version and Tomcat version.
- Back up the current WAR file and, if possible, the application data.
- Upload the new WAR through the panel, File Manager, or FTP.
- Replace the existing deployment according to the hosting platform’s process.
- Restart the Tomcat service if required.
- Review the logs and test the application.
If your hosting plan supports several Java or Tomcat versions, make sure the app is deployed to the correct service before uploading the update. A WAR that works on one Java runtime may fail on another if it relies on an older API, a newer servlet feature, or a dependency compiled for a specific version.
Safe update checklist
- Confirm the correct context path.
- Check compatibility with the selected Java version.
- Back up the existing deployment and config files.
- Preserve external data directories used by the application.
- Test after deployment, not only after restart.
Working with WAR files, JSP apps, and servlet deployments
Tomcat hosting is often used for WAR deployments because they are portable and easy to replace. JSP sites and servlet applications also benefit from a private JVM and a defined application server environment. In a managed hosting setup, the goal is usually to make deployment repeatable: upload, restart if needed, verify logs, and test.
For WAR-based updates, pay attention to these points:
- Do not overwrite files that contain user data unless that is part of the update plan.
- Keep external configuration outside the application package when possible.
- Use the same build settings for local testing and hosted deployment.
- Verify that static resources, JSP pages, and compiled classes are included correctly.
If your app uses session data, file uploads, or cached content, a redeploy may clear runtime state. That is normal for many Tomcat setups, but it means you should schedule updates carefully and avoid making changes during peak traffic if the app is in active use.
Using Java and Tomcat version control wisely
One practical advantage of hosted Java services managed through Plesk is version choice. If your hosting platform offers several ready-to-install Tomcat or Java versions, select the one that matches your application dependencies. This can reduce startup failures and save time during updates.
Choose a newer runtime when your application supports it and benefits from security or platform improvements. Keep an older version only when the application still depends on it and you have tested it properly. If you upload a custom app server package, verify that the version is compatible with your build output and any framework libraries you use.
Good version management reduces the number of restart-related incidents because the application is less likely to fail during startup. It also makes log analysis easier, since a version mismatch becomes less likely to hide behind unrelated errors.
Common log errors and what they usually mean
Many Tomcat hosting problems can be identified quickly once you know the common log patterns. The exact wording may differ by application, but the meaning is often similar.
- Port already in use — another service is using the configured Tomcat port.
- ClassNotFoundException — a required class or dependency is missing from the WAR or library path.
- UnsupportedClassVersionError — the app was compiled for a newer Java version than the service provides.
- Failed to deploy application — the WAR may be corrupt, incomplete, or incorrectly packaged.
- Permission denied — Tomcat cannot write to a directory it needs for temp files or logs.
- Database connection refused — the application cannot reach the database host, port, or credentials.
When you see one of these errors, do not assume Tomcat itself is broken. In hosted environments, the application layer is often the real issue. The server service is simply reporting the problem during startup or request handling.
Best practices for updates and restarts in managed hosting
To keep your Tomcat hosting stable, use a repeatable maintenance routine. This is especially useful when you manage a small Java app, a JSP site, or a servlet service through a control panel.
- Always review logs before and after deployment.
- Keep a backup of the last working WAR.
- Change one thing at a time where possible.
- Restart only when the update or fix requires it.
- Test the homepage, login flow, and any critical endpoints after each release.
- Document the Java version, Tomcat version, and deployment date.
This approach makes support easier too. If you need assistance from the hosting provider, a clear record of the error, restart time, and update version helps identify the issue faster.
Troubleshooting if Tomcat does not start after an update
If the service fails after a new deployment, use a simple recovery sequence. First, check the most recent log entries. Then compare the new package with the previous working version. If the problem appeared immediately after the update, restore the prior WAR and test again. This helps separate a deployment issue from a deeper server problem.
In many cases, the cause is one of the following:
- Incorrect Java compatibility.
- Missing configuration file or environment variable.
- Broken library dependency.
- Wrong file permissions after upload.
- Unexpected change in the application context path.
If you are using a hosting platform with a managed Java service, you may also need to verify the service settings in the panel. For example, a changed Java version or custom Tomcat configuration can affect startup even when the application package itself is correct.
FAQ
Where do I find Tomcat logs in a hosting control panel?
Usually in the Java service management area, under logs, service details, or application logs. If they are not shown there, check the account file system through File Manager or FTP for the instance-specific log files.
Do I need to restart Tomcat after every WAR upload?
Not always, but it is often recommended if the hosting platform does not auto-redeploy the application. Restarting ensures the new WAR is fully loaded and the previous runtime state is cleared.
Why does my JSP app work locally but fail on hosted Tomcat?
The most common reasons are Java version differences, missing dependencies, hard-coded paths, or differences in file permissions and environment settings. The logs usually reveal the exact cause.
Can I run my own Tomcat version on a shared hosting account?
If your hosting plan includes private Java hosting or a custom application server feature, you may be able to install and manage your own Tomcat instance within the account limits. The available versions and service controls depend on the platform.
What should I back up before an update?
Back up the current WAR, custom configuration files, external data directories, and any uploaded assets or database-related files that are not generated by the build.
How do I know whether a problem is in Tomcat or in my application?
If the logs show a startup failure before your app code is loaded, the issue may be in the server configuration or package structure. If Tomcat starts normally but the app returns errors, the problem is more likely in the application code or its dependencies.
Conclusion
Managing logs, restarts, and updates on Tomcat hosting is mostly about using the control panel effectively and reviewing the right files at the right time. In a managed Java hosting setup with Plesk and My App Server, you can usually inspect service logs, restart the Tomcat instance, and deploy WAR updates without direct server administration. That makes it practical for JSP, servlet, and small to medium Java applications that need a private JVM and simple service control.
For the best results, keep your deployments consistent, verify Java and Tomcat compatibility, and check logs before making repeated restarts. This helps you resolve problems faster and maintain a more stable hosting environment for your application.