When you maintain a live Tomcat site, the safest approach is to treat every restart, redeploy, or configuration change as a controlled operation. In a hosted Java environment, especially when you manage Tomcat through Plesk and a service such as My App Server, the goal is not only to bring the application back online quickly, but to reduce the chance of session loss, failed deployments, and avoidable downtime.
Lower-risk maintenance means planning for the application state, the JVM, the Tomcat process, and the traffic that may still be hitting the site while changes are made. It also means using the control panel tools available to you, checking logs before and after the change, and keeping a rollback path ready in case the update does not behave as expected.
What lower-risk maintenance means for a live Tomcat application
For a live Tomcat site, maintenance usually includes one or more of the following: restarting the Tomcat service, deploying a new WAR file, changing Java settings, updating application configuration, or replacing application resources. Each of these actions can affect active users.
Lower-risk maintenance aims to minimise four common problems:
- Unexpected downtime while Tomcat restarts or the app redeploys.
- Session loss for users who are mid-request or logged in.
- Configuration drift between the running environment and the files on disk.
- Slow recovery when something fails and the old version is not easy to restore.
In a managed hosting setup with a private JVM or private Tomcat instance, you have more control than in a shared application runtime. That control is useful, but it also means you should plan changes carefully so that the service remains stable throughout the maintenance window.
Plan the change before touching the live service
The most reliable maintenance starts before you click restart or upload a new package. A few minutes of preparation can save hours of recovery work later.
1. Identify exactly what will change
List the files, settings, or runtime components that will be affected. For example:
- Updated WAR file or exploded application directory
- New Java version selected in My App Server
- Changed JVM options such as memory settings or system properties
- Edited web.xml, server.xml, or application property files
- Updated database credentials or external service endpoints
If the change affects startup behaviour, JVM memory usage, servlet mappings, or class loading, treat it as a higher-risk operation and plan for validation after the restart.
2. Check whether the application can tolerate a restart
Some Tomcat applications handle brief interruption cleanly. Others keep long user sessions, open uploads, or background jobs that can fail if Tomcat restarts at the wrong moment.
Before maintenance, confirm whether your application uses:
- in-memory sessions that will be lost on restart
- file uploads in progress
- scheduled jobs or queues inside the JVM
- temporary files stored under the app directory or Tomcat temp folders
- external connections that need to reconnect after startup
If the application is stateful, it is better to schedule the work for a quiet period and warn users in advance.
3. Prepare a rollback copy
Always keep the previous working version available. In Tomcat hosting, rollback is usually easiest when you keep:
- the previous WAR file
- a backup of configuration files
- the last known good Java version setting
- notes about any manual changes made in Plesk or My App Server
Do not rely on memory. If a restart fails or the new deployment does not start, you want a clear path back to the last stable state.
Use the hosting control panel to reduce operational risk
When Tomcat is managed through Plesk and My App Server, the control panel becomes part of your maintenance workflow. This is an advantage because it gives you a consistent place to manage the service, the Java runtime, and the deployment process.
Prefer service controls over ad hoc process changes
If the platform provides a service control option, use it rather than trying to stop or start the JVM manually from shell commands unless you specifically need that level of access. Service controls are usually safer because they keep the platform aware of the process state and help avoid orphaned processes or incomplete restarts.
A proper service restart should:
- stop the current Tomcat process cleanly
- release ports and file locks
- start the configured version of Tomcat or the private JVM
- preserve the expected service identity inside the hosting account
Verify the selected Java and Tomcat version
One of the practical benefits of My App Server is that you can choose a Java/Tomcat version that matches your application requirements. Before maintenance, confirm that the selected runtime is the one your app expects. A restart after a version change is not a routine restart; it is a runtime migration and should be treated as such.
Check:
- Java major version compatibility
- Tomcat version compatibility with your app
- Any required JVM flags or environment variables
- Whether a custom app server configuration was manually added
If the application runs on a specific Java release, avoid switching versions during the same maintenance window unless the change has already been tested.
Use separate environments where possible
Even in a small or medium hosting setup, it helps to maintain a staging copy or at least a test deployment path. If you can verify the update in a non-live environment first, do it. Testing the same WAR file, the same Java version, and the same JVM settings is one of the simplest ways to reduce risk.
How to schedule maintenance for a live Tomcat site
The timing of the change matters. A brief restart during low traffic may be acceptable, while the same action during peak usage may create visible errors or user complaints.
Choose a quiet maintenance window
Select a time when traffic is usually lower. For business applications, this may mean early morning or outside local office hours. For public websites, check historical access patterns and avoid high-traffic periods.
When choosing a maintenance window, consider:
- daily traffic peaks
- batch jobs or scheduled imports
- customer-facing deadlines
- external integrations that may retry requests during downtime
Announce the maintenance if users may be affected
If there is any chance of visible downtime, communicate it clearly. Even a short restart can interrupt logins, form submissions, and API calls. A brief notice reduces support tickets and helps users understand the interruption.
For internal teams, share:
- the maintenance start and end time
- what will be changed
- expected impact on the site or API
- who to contact if the service does not return as expected
Freeze changes during the maintenance window
Do not let multiple people upload files, edit configs, or restart services at the same time. Conflicting changes are a common cause of failed deployments and hard-to-diagnose issues. Assign one person to make the change and one person to verify the result.
Practical steps to restart Tomcat with lower risk
A clean restart is usually safer than a forced restart, especially when the site is live. The following sequence helps reduce the chance of problems.
Step 1: Check the current service state
Confirm whether Tomcat is running, whether the application is already reporting errors, and whether any recent log entries show warnings. If the service is unstable before you begin, note that your restart may reveal an existing issue rather than create a new one.
Step 2: Review logs before the restart
Look at the application logs and the Tomcat logs for current errors. Common early warnings include:
- failed database connections
- classpath or JAR loading problems
- permission errors on temp or cache directories
- memory pressure or out-of-memory warnings
- binding errors on ports or connectors
If the logs already show repeated failures, restarting without fixing the root cause may only shorten the time until the next incident.
Step 3: Save any live configuration state
If the application uses admin settings, export or record them before the restart. Some applications store settings in memory and write them later. Others depend on external databases or flat files. Knowing where the current state lives makes rollback much easier.
Step 4: Stop Tomcat cleanly from the service controls
Use the available service control in the hosting panel to stop Tomcat. Allow enough time for active requests to finish where possible. A graceful stop is generally safer than a forced stop because it gives the JVM a chance to flush buffers, close resources, and shut down background threads cleanly.
Step 5: Wait for the process to fully exit
Do not restart immediately if the platform still shows the service as stopping or if ports remain in use. Starting a second instance too early can create a conflict, especially if the old process did not exit cleanly.
Step 6: Start the service and verify the startup log
After the restart, read the startup log rather than assuming success. A Tomcat service may start but still fail to deploy the application correctly. Look for:
- successful connector startup
- application context deployment
- database connection initialisation
- absence of severe exceptions during startup
Step 7: Test the most important user paths
Do not stop at the homepage. Verify the actions that matter most to your users, such as login, form submission, file upload, search, or API endpoints. If the site depends on JSP or servlet routes, check those specifically.
Safer deployment practices for WAR, JSP and servlet applications
In Tomcat hosting, many maintenance tasks are actually deployments. The same risk rules apply whether you are restarting the service or replacing the application package.
Deploy one change at a time
Changing the application version, Java version, and JVM memory at the same time makes troubleshooting difficult. Separate runtime changes from application changes where possible. If something breaks, you will know which layer caused it.
Keep deployment packages consistent
Make sure the WAR file, configuration files, and any static assets belong to the same release. Mixing old and new files can produce class loading issues, missing resources, or inconsistent behaviour after restart.
Avoid incomplete manual edits on the live app directory
Directly editing files inside the deployed application can be risky if Tomcat is running. If you must apply a manual fix, do it carefully and document exactly what changed. In many cases, replacing the full package is safer than modifying individual files in place.
Pay attention to temp and cache directories
Some applications store temporary data in Tomcat temp folders or under the application path. These files can survive a restart in some setups and disappear in others. Before maintenance, understand what should be preserved and what can be regenerated.
How to reduce the impact of downtime
Even a short service interruption can be noticed by users. The objective is to keep downtime as brief and predictable as possible.
Use a short and realistic maintenance window
Do not over-promise. If a restart usually takes two minutes but deployment and verification take ten, schedule for the full ten. Underestimating the window causes pressure and increases the chance of mistakes.
Prepare a lightweight health check
Have one or two simple URLs ready to confirm that the application is alive after restart. A good health check should verify the app is responding, not just that the web server returns a page. Examples include:
- a status page
- a login page
- a simple servlet endpoint
- a page that confirms database connectivity if needed
Watch for session-related issues after restart
If users must log in again or lose unsaved progress after maintenance, that may be normal for the app, but it should be expected and communicated. If session behaviour changes unexpectedly after a restart, review session storage, timeouts, and any application settings that affect persistence.
What to check after the service comes back online
The restart is not finished when the panel says the service is running. Post-maintenance verification is where many hidden issues are caught early.
- Confirm the site loads over HTTP and HTTPS if applicable.
- Check that Tomcat is using the intended Java version.
- Review recent logs for warnings, exceptions, and deployment errors.
- Test login, forms, and any route that touches the database.
- Verify file uploads, downloads, or integration endpoints.
- Make sure background jobs have resumed if your app depends on them.
If the application is part of a wider stack with Apache in front of Tomcat, confirm that the proxy or connector path is still working correctly after the restart.
Common mistakes that increase maintenance risk
Most avoidable incidents come from a few recurring mistakes.
Restarting without checking logs
If the application already shows errors, a restart may hide the symptom briefly but not fix the cause. Always review logs first.
Making changes during active usage
Deploying while users are actively submitting forms or completing transactions increases the chance of partial failures and support issues.
Changing too many variables at once
Updating the application, the Java version, and the server settings in one go makes debugging much harder.
Skipping rollback planning
If something fails, the lack of a ready rollback often turns a short maintenance task into an extended outage.
Ignoring dependency changes
Even when the WAR file is unchanged, external services, database schemas, or environment variables may have changed. A Tomcat restart can expose those dependencies immediately.
Recommended maintenance checklist
Use this checklist before and during a live Tomcat maintenance operation:
- Confirm the exact change you are making.
- Back up the current WAR and configuration files.
- Verify the current Java and Tomcat versions.
- Check recent logs for existing errors.
- Choose a low-traffic maintenance window.
- Notify users or internal staff if needed.
- Freeze other changes during the window.
- Use the hosting control panel service controls.
- Wait for a clean stop before starting again.
- Review startup logs after the service comes back.
- Test the most important user flows.
- Keep the previous version available for rollback.
When to seek additional help
If Tomcat does not start after a restart, or if the application deploys but fails during initialisation, the issue may involve permissions, classpath conflicts, memory settings, or an application-specific dependency. In a hosted environment, it is often faster to gather the relevant logs and settings before opening a support request.
Useful information to provide includes:
- the time of the maintenance action
- the exact change performed
- Tomcat and Java versions in use
- recent log excerpts around the failure
- any rollback attempt already made
FAQ
Can I restart Tomcat on a live site without downtime?
In most cases, no. A standard Tomcat restart briefly interrupts active requests and can affect logged-in users. You can reduce the impact by choosing a quiet time, but a fully seamless restart usually requires a more advanced architecture than a typical private JVM hosting setup.
Is it safer to restart from Plesk or from the command line?
When the hosting platform provides service controls in Plesk or a dedicated extension such as My App Server, that is usually the safer option. It keeps the service state consistent and reduces the chance of incomplete stops or orphaned processes.
Should I change the Java version during maintenance?
Only if the change is planned and tested. A Java version change can affect library compatibility, startup behaviour, and runtime stability. Treat it as a separate maintenance task whenever possible.
What is the safest way to deploy a new WAR file?
Keep a copy of the current working version, deploy during a low-traffic period, and verify the startup log plus the main user paths after the deploy. Avoid combining the WAR update with unrelated configuration changes unless necessary.
Why does the app sometimes work after restart but fail later?
Some problems only appear under load, after cached data expires, or when a background job runs. That is why post-startup testing should include real user flows and not only the homepage.
Can I use this approach for JSP and servlet applications too?
Yes. The same lower-risk maintenance principles apply to JSP hosting, servlet hosting, and Tomcat-based Java hosting in general: plan the change, back up the current state, restart cleanly, verify logs, and test after the service returns.
Conclusion
Lower-risk maintenance for a live Tomcat site is mostly about preparation, timing, and verification. In a hosting setup with Plesk and My App Server, you have practical tools to manage Tomcat, choose compatible Java versions, and control the service from one place. Use those tools carefully, keep a rollback path ready, and always confirm the application behaves correctly after the restart or deployment.
When changes are planned in small steps and checked against logs, the chance of avoidable downtime drops significantly. That is the safest way to maintain a live Tomcat application without turning a routine update into an incident.