A Tomcat application should be restarted only when there is a clear operational reason. In a managed hosting environment, restart is usually the fastest way to recover from a stuck process, load a new deployment, apply a configuration change, or switch Java/Tomcat versions after maintenance. At the same time, unnecessary restarts can interrupt users, clear in-memory state, and make troubleshooting harder.
If you are using a hosted Java environment such as My App Server in Plesk, the best practice is to restart Tomcat deliberately and only after checking logs, service status, and recent changes. For small and medium Java apps, JSP sites, servlet applications, and WAR-based deployments, a restart is often a normal part of safe operations — but it should be the exception, not the default response to every issue.
When a Tomcat restart is the right choice
Restart Tomcat when the application or runtime needs a clean reload and other corrective actions are not enough. Common situations include:
- Application is stuck or unresponsive and requests are timing out.
- Memory usage keeps growing and does not recover, suggesting a leak or a process that needs a fresh JVM.
- Deployment changes are not taking effect after uploading a new WAR, JSP, or configuration file.
- Java version or Tomcat version changed and the service must start again to use the new runtime.
- Config files were updated for the application, connector, JVM options, or environment variables.
- Background threads or sessions are in a bad state and the app needs a clean start.
- Recovery after a crash when Tomcat stopped unexpectedly and must be brought back online.
In a shared hosting account with a private JVM, restart is also a practical way to reinitialize the application after changes made through the control panel, especially when using Plesk and a Java hosting extension like My App Server.
When you should avoid restarting Tomcat immediately
Do not restart first if the root cause is still unknown. A restart can hide useful clues and may temporarily mask a problem that will return later. Before restarting, check whether the issue could be caused by:
- a broken database connection;
- an expired certificate or authentication failure;
- missing permissions for files or directories;
- a full disk, quota limit, or inode limit;
- incorrect environment variables;
- a bad deploy or incompatible library;
- an external dependency outage;
- application-level errors that appear only in logs.
If the application is still responding, it is usually better to inspect logs and service status first. A restart should be part of a planned recovery step, not a substitute for diagnosis.
Typical signs that a restart may be needed
You will often see a combination of operational symptoms rather than one single error. Watch for:
Slow response or timeouts
Pages load very slowly, API requests time out, or the application stops responding under normal traffic. This can indicate a hung thread, resource exhaustion, or a JVM state that a restart may clear.
HTTP 500 errors after a deployment
If a new release was deployed and the app started returning internal server errors, restart may be needed to reload classes, configuration, or the full context.
Stale content or old code still running
Sometimes a Tomcat application keeps serving old behavior after new files were uploaded. That may happen when the deployment did not fully complete, cached components remain active, or the application needs a full restart to rebuild its runtime state.
Memory pressure
High heap usage, frequent garbage collection, or the JVM being killed by the system are strong indicators that the process should be restarted after you inspect the cause.
Logs show repeated fatal errors
If the same error appears again and again in catalina logs, application logs, or stdout/stderr output, and the service does not self-recover, a restart may be necessary after correcting the underlying issue.
What to check before restarting in Plesk or My App Server
Before using the restart button in your control panel, review a few basics. This helps you avoid unnecessary downtime and choose the right recovery action.
- Check the service status in the control panel and confirm whether Tomcat is running, stopped, or failing to start.
- Review recent changes such as new WAR upload, config edits, Java version switch, or updated environment variables.
- Inspect logs for stack traces, startup errors, port conflicts, permission problems, or missing classes.
- Verify resource usage including memory, CPU, disk space, and account limits.
- Confirm dependencies such as database access, external API endpoints, and file system permissions.
- Check whether the application can be fixed without restart, for example by correcting a config file and reloading only the affected component if your app supports it.
In managed hosting, these checks can usually be done quickly through the hosting panel. If your environment uses My App Server, the service controls are designed to make Tomcat management straightforward while keeping the application isolated inside the hosting account.
Safe restart procedure for a Tomcat application
Use a controlled restart process to reduce downtime and prevent data loss. For most hosted Tomcat applications, the general approach is:
- Notify users if needed if the application is customer-facing or handles live transactions.
- Check logs first to see whether the problem points to a specific configuration or deploy issue.
- Make a quick backup of important application files, configuration, or custom data if the change is significant.
- Stop the Tomcat service cleanly rather than killing the process abruptly, if the control panel allows it.
- Wait for shutdown to complete so open files and sessions can close properly.
- Start the service again and verify that the JVM and Tomcat instance come up normally.
- Test the application by opening the main page, checking a servlet or JSP endpoint, and confirming database access if applicable.
- Recheck logs after startup for startup warnings, port binding issues, or deployment errors.
If Tomcat does not stop cleanly, do not force restart immediately unless the instance is fully hung and you have already checked the logs. A forced action should be a last resort.
Restart scenarios in a hosted Java environment
In a hosting platform like ITA’s Java hosting with My App Server, restart needs can be grouped into a few practical scenarios.
After a WAR deployment
If you uploaded a new WAR file and the application still behaves like the old version, a restart may help reload the deployment cleanly. This is especially useful when classloading, old sessions, or cached resources are involved.
After switching Java version
When you change the Java version in the control panel, the application must be restarted so the new JVM is used. This is common when testing compatibility between application code and a specific Java release.
After updating Tomcat
When Tomcat itself is updated or replaced with another version, restart is required so the service starts with the new binaries and configuration. In a managed hosting account, this is usually done through the service controls.
After editing JVM options
Heap size, garbage collection flags, encoding, timezone, or custom JVM parameters usually take effect only after a restart. If you changed startup settings, always restart and then confirm the runtime picked them up correctly.
After fixing file permissions
If the application could not read a config file, static asset, or upload directory, a restart may be needed after permissions are corrected so the app can reopen resources cleanly.
Restart versus redeploy versus cache clear
Not every problem requires a Tomcat restart. Choosing the least disruptive fix is usually best.
- Restart when the JVM or Tomcat process itself needs a fresh start.
- Redeploy when the application package changed and the new version must be loaded.
- Clear application cache when only cached data, templates, or session-related content is stale.
- Reload configuration if your application supports it without a full stop/start cycle.
If your app has built-in admin tools, it may be enough to clear its own cache or restart only the application context. However, in many hosted Tomcat setups, a full service restart is still the simplest and safest way to ensure consistency.
How to reduce downtime during a restart
Even a short restart can affect active users, so plan it carefully.
- Choose a low-traffic time when possible.
- Keep the restart window short by preparing backups and checks in advance.
- Inform stakeholders if the application is used by customers or staff.
- Verify health immediately after startup to catch failures early.
- Use logs to confirm success instead of assuming the service is healthy because the process is running.
For small hosted applications, a restart may take only a short time, but users can still experience errors if the app is not fully ready. Always test more than the main landing page.
What to verify after restarting Tomcat
After the service comes back online, check the following:
- Tomcat started without fatal errors in the logs.
- The application context deployed successfully.
- The expected Java version is active.
- Web pages, servlets, and JSPs respond normally.
- Database connections work.
- Uploads, sessions, and background jobs behave as expected.
- No repeated warnings or errors continue to appear after startup.
If the application fails again immediately after restart, the problem is likely not the service state itself. In that case, focus on startup logs, deployment files, environment settings, or a dependency failure.
Common mistakes to avoid
- Restarting repeatedly without checking logs or root cause.
- Forcing a stop too early and risking incomplete writes or session loss.
- Changing multiple settings at once so you cannot tell what caused the issue.
- Ignoring resource limits such as memory, disk, or account quotas.
- Assuming a restart fixed the problem without testing the affected function.
For managed Tomcat hosting, the most reliable approach is to make one controlled change at a time and confirm the result before moving to the next step.
Recommended restart decision guide
Use this simple rule of thumb:
- Restart now if Tomcat is frozen, unresponsive, or requires a clean reload after a deployment or configuration change.
- Investigate first if the app is showing errors but still responds, or if the cause is unclear.
- Fix the underlying issue first if logs show permission problems, missing files, database errors, or an invalid configuration.
- Use service control tools in Plesk or My App Server when you need a safe stop/start cycle for a private JVM or hosted Tomcat instance.
FAQ
Should I restart Tomcat after every deployment?
Not always, but it is often the safest choice if you changed classes, libraries, JVM options, or key configuration files. For WAR-based applications, restart helps make sure the new version is fully loaded.
Can a Tomcat restart fix HTTP 500 errors?
Sometimes, especially when the error is caused by a stuck JVM state, incomplete deployment, or stale classes. If the same 500 error returns after restart, the real issue is likely in the application or its dependencies.
Will restarting Tomcat delete my data?
A normal restart should not delete application data, but in-memory sessions and unsaved runtime state may be lost. Always make sure important data is stored persistently before restarting.
How do I know if Tomcat did not restart correctly?
Check the service status and logs. If the process starts and then exits, or if the application does not deploy after startup, the logs usually show the reason, such as a port conflict, missing class, or invalid Java setting.
Is restarting better than killing the process?
Yes. A clean stop/start is preferred because it allows Tomcat to close resources properly. Killing the process should be used only when the service is completely hung and cannot stop normally.
Do I need to restart after changing Java version in My App Server?
Yes. A Java version change takes effect only when the service starts again with the selected runtime. After restarting, confirm that the application is running on the expected Java version.
What if the app still does not work after restart?
Then the issue is probably not a temporary service state. Review the logs, deployment files, permissions, database connectivity, and any recent changes. If needed, roll back the last change and test again.
Conclusion
Restart a Tomcat application when it is the correct operational response: after a deployment, after a Java or Tomcat change, when the JVM is stuck, or when a clean recovery is needed. Avoid using restart as the first and only troubleshooting step. In a hosted environment with Plesk and My App Server, the best results come from checking logs, confirming service status, and restarting only when there is a clear reason.
Used carefully, a restart is a simple and effective way to recover small and medium Tomcat-based applications, refresh a private JVM, and keep a hosted Java service healthy with minimal disruption.