When a Java web application starts behaving unexpectedly, the fastest way to find the cause is usually in the application logs. In a hosting environment, those logs often tell you whether Tomcat started correctly, whether your WAR was deployed, whether a database connection failed, or whether a servlet threw an exception after a request reached the app.
If you are using a managed hosting setup with Plesk and My App Server, log reading is especially useful because you can inspect what the private JVM and Apache Tomcat instance are doing without needing full server access. This is often the difference between guessing and fixing the problem quickly.
On this page you will learn how to read Java application logs when something goes wrong, which log files matter most, how to recognise common Tomcat and Java errors, and how to use the logs together with Plesk and service controls to narrow down the issue.
Which logs you should check first
For Java hosting and Tomcat hosting, there is rarely just one log file. The best approach is to check the logs in a practical order, starting with the ones most likely to show the root cause.
1. Application log
This is the main log generated by your application or by the framework running inside Tomcat. It is the first place to look when a page returns an error, a feature stops working, or the app behaves differently after a deploy.
Typical things you may see here:
- Java exceptions
- Stack traces
- Configuration errors
- Missing file or permission problems
- Database connection failures
2. Tomcat logs
Tomcat logs are important when the problem affects startup, deployment, or the application container itself. In a My App Server setup, Tomcat is often the layer that shows whether the service started, whether the context was deployed, or whether a port conflict or memory issue prevented the app from running properly.
Look for entries related to:
- startup and shutdown events
- deployment of WAR files
- context initialisation
- JSP compilation
- connector or port errors
3. Java JVM or service log
If your app is running in a private JVM, the service log can show issues such as failed startup, incorrect Java version selection, memory pressure, or process termination. This is particularly useful when the application does not even reach the point where Tomcat fully loads.
4. Web server and proxy logs
Sometimes the Java app is fine, but Apache or another front-end layer returns the error. In that case, check the web server logs to see whether the request reached Tomcat at all. This helps you distinguish between a Java problem and a routing, proxy, or web server issue.
How to find the most useful error in the log
Large logs can be noisy. The key is to search for the first meaningful error, not the last one. A later error is often only a consequence of an earlier failure.
Start near the time the problem happened
If you know the exact time the issue occurred, open the log around that timestamp. This is the fastest way to narrow the scope. If the site stopped working at 14:20, do not begin at the end of a 500 MB log file.
Look for the first Exception
Common Java logs include stack traces. The line that names the exception is usually more important than the repeated stack frames that follow it. For example:
- NullPointerException usually indicates that a value was missing or not initialised.
- ClassNotFoundException suggests a missing library or deployment issue.
- SQLException points to a database or connection problem.
- BindException may indicate a port conflict.
- OutOfMemoryError means the JVM ran out of memory.
Ignore repeated stack trace lines until the root message is found
A stack trace can look intimidating, but the useful part is usually near the top of the error block. The lines after that show the chain of method calls. Read them only after identifying the exception type and message.
Check for timestamps and thread names
Timestamps help you connect the log entry to a user action, deploy, restart, or scheduled task. Thread names are useful when multiple requests are being handled at once. If the same error appears repeatedly in different threads, the issue is likely application-wide rather than a single request problem.
Common Java and Tomcat log messages and what they mean
Below are some of the messages most often seen in Java hosting logs and how to interpret them in a hosted Tomcat environment.
Startup errors
If Tomcat does not start correctly, you may see messages related to the JVM, classpath, ports, or configuration files.
- Address already in use — another process is using the same port.
- Could not reserve enough space for object heap — the JVM could not allocate the memory requested.
- Invalid JAVA_HOME or similar — the Java installation path is wrong.
- SEVERE: Error starting static Resources — often related to deployment or filesystem access.
Deployment errors
If you upload a WAR file or update an application and it does not appear online, look for deployment messages in the Tomcat logs.
- Failed to deploy web application archive — the WAR could not be unpacked or loaded.
- Context path already in use — another app or context is using the same path.
- ClassNotFoundException during startup — a required library is missing from WEB-INF/lib or the build output.
- Unsupported major.minor version — the application was compiled for a newer Java version than the one currently selected.
Runtime application errors
These are the errors that usually affect users after the app is already running.
- NullPointerException — a variable or object was not available when the code expected it.
- IllegalArgumentException — the app received an invalid value, such as a bad date, ID, or parameter.
- SQLException — database query failed, connection timed out, credentials were wrong, or schema was unavailable.
- FileNotFoundException — the app tried to read or write a file that does not exist or is not accessible.
- OutOfMemoryError — memory pressure is high and the JVM cannot continue safely.
Request and HTTP errors
Sometimes the log shows a request-level problem rather than a code failure.
- 404 — the resource or route was not found.
- 403 — access was denied.
- 500 — the server encountered an application error.
- 503 — the service may not be running or is temporarily unavailable.
Step-by-step: how to diagnose a problem from logs in Plesk
If you are using My App Server in Plesk, follow this practical process whenever something goes wrong.
Step 1: Confirm the symptom
Start with the user-facing problem. Is the app not loading at all, returning an error page, missing only one feature, or failing after a new deploy? Different symptoms point to different log areas.
Step 2: Check whether the service is running
Use the service controls in Plesk to see if the Java service or Tomcat instance is active. If the service stopped, the logs will usually explain why. If it is running but the site still fails, the issue may be inside the application.
Step 3: Open the most recent log entries
Check the latest lines in the application log and Tomcat log. If the problem started after a restart or deploy, the relevant error is often close to the end of the previous startup sequence.
Step 4: Search for the first error after the last successful event
Look for the point where startup changed from normal informational messages to warnings or errors. In Java logs, the first error before the failure is the one that matters most.
Step 5: Match the timestamp with a request or action
Did the issue begin after a deployment, configuration change, restart, or traffic spike? Matching timestamps helps you separate a code problem from an operational one.
Step 6: Check related logs
If the application log is unclear, inspect the Tomcat log, JVM log, and web server log. A failure in one layer often appears as a symptom in another layer.
Step 7: Test one change at a time
After identifying a likely cause, make one correction only, then review the logs again. This helps you confirm whether the fix worked and avoids hiding the original problem behind a new one.
How to read a Java stack trace without getting lost
A stack trace is one of the most important things in a Java application log. It looks technical, but there is a simple way to read it.
Find the exception type
The first line of the error block usually says what went wrong, for example NullPointerException or SQLException. This gives you the broad category of the issue.
Read the message after the exception
Many exceptions include a short message such as a missing table name, an invalid path, or a specific configuration value. That short message is often the real clue.
Identify your code first
In the stack trace, look for lines that point to your application packages, not only framework classes. If the trace mentions your servlet, controller, filter, or helper class, that is usually where you should begin debugging.
Distinguish cause from consequence
One exception may wrap another. For example, a database error may trigger a higher-level servlet exception. The inner or root cause is usually the one with the real explanation.
Use line numbers
When logs include line numbers, they are extremely helpful. They tell you where in the source code the exception occurred, which is especially useful in JSP, servlet, and framework-based applications.
Practical examples of log reading
Example 1: Application returns a 500 error after login
If login works only partly or returns a 500 error, check the application log for an exception at the exact time of the request. Common causes include a database problem, a missing session attribute, or an authentication configuration error.
What to look for:
- authentication-related exceptions
- missing user records
- database timeouts
- invalid redirect or session handling
Example 2: Tomcat starts, but the app is not available
In this case, the service may be running, but deployment may have failed. Check the Tomcat log for messages about the WAR file, context path, or missing libraries. The log often shows whether the application was unpacked successfully.
Example 3: The app worked yesterday, then failed after an update
Compare the log entries before and after the deploy. Look for:
- new exception types
- classpath changes
- Java version incompatibility
- configuration file changes
- missing environment variables or resource names
Example 4: Pages load slowly or time out
Slow response is sometimes visible in the logs as repeated timeouts, long database queries, connection pool warnings, or memory pressure. If the app is under load, the logs can show whether the problem is the code, the database, or JVM resources.
Using logs together with My App Server controls
In a shared hosting environment with a private JVM, logs are most useful when combined with service controls. If you can start, stop, or restart the Java service from Plesk, you can check whether the app recovers after a clean restart and whether the same error appears again.
When to restart and check logs again
Restarting the service can be useful after:
- a configuration correction
- a new deployment
- a Java version change
- an updated memory setting
After restart, inspect the startup log again. If the same failure returns immediately, it is usually a configuration, deployment, or compatibility issue rather than a temporary glitch.
When not to restart repeatedly
Repeated restarts without reading logs can make the problem harder to diagnose, especially if the logs roll over or the original error message is overwritten. Always capture the first failure before trying multiple restarts.
What to check if the log is empty or incomplete
Sometimes the problem is not the application itself but the logging setup. If you do not see useful log entries, consider these points:
- The application may be logging to a different file or directory.
- Log level may be too high, hiding warnings and debug messages.
- The app may not have permission to write to the log location.
- Disk space may be low, preventing new entries from being written.
- Rotation settings may have moved the relevant log into an archived file.
If you uploaded a custom Tomcat instance or configured logging manually, verify the paths and file permissions carefully. A missing log file can itself be a useful clue.
Good log-reading habits for hosted Java apps
To diagnose issues faster, use a few simple habits whenever you manage Java hosting or Tomcat hosting.
- Keep a note of deploy times and configuration changes.
- Check the newest error first, then trace back to the first root cause.
- Compare application logs with Tomcat and web server logs.
- Look for repeating patterns rather than isolated lines.
- Use timestamps to connect logs with user actions.
- Save the exact exception message when asking for support.
These habits make it easier to debug issues in a hosted environment where you may not have direct access to every layer of the stack.
When to contact support
Contact hosting support if the logs indicate a platform-level issue rather than an application bug. For example, reach out if Tomcat will not start, the private JVM fails before the app loads, the service control shows a problem you cannot resolve, or you cannot access the relevant logs from Plesk.
To help support investigate quickly, include:
- the exact time the issue occurred
- the application name or context path
- the relevant log excerpt
- what changed before the problem started
- any restart or redeploy steps already tried
FAQ
What is the first log file I should check for a Java application error?
Start with the application log, then check Tomcat logs if the problem looks related to startup, deployment, or the container itself. If the service will not start, the JVM or service log is also important.
How do I know if the problem is in my code or in Tomcat?
If the logs show a Java exception inside your application classes, the issue is usually in the app code or configuration. If the logs show startup, port, deployment, or service errors before the app loads, the issue is more likely in Tomcat, the JVM, or the hosting configuration.
What does a 500 error mean in a Java hosting log?
A 500 error usually means the request reached the server but the application failed while processing it. Check the exact timestamp and look for the corresponding exception or stack trace in the application log.
Why does the app work after restart but fail later?
This often points to memory pressure, a temporary database issue, an expired session, or a hidden configuration problem. Check whether the same error appears again after some time and whether the logs show warnings before the failure.
Can I use logs to debug WAR deployment problems?
Yes. Tomcat logs are especially useful for WAR deployment issues. They can show whether the archive was unpacked, whether the context path was registered, and whether any library or version mismatch prevented startup.
What if the log says ClassNotFoundException?
This usually means a required class or library is missing. Check your deployed files, WEB-INF/lib content, build output, and Java version compatibility. In hosted environments, also confirm that the app was uploaded completely.
Do I need full server access to read logs in My App Server?
No, in many cases Plesk gives you access to the relevant application and service logs. That is one of the practical advantages of using a hosted Tomcat setup with control panel management.
Conclusion
Reading Java application logs is one of the most reliable ways to diagnose issues in a hosted Tomcat environment. Whether the problem is a startup failure, a broken deployment, a database timeout, or a runtime exception, the logs usually show the real cause long before the user sees an error page.
In a managed hosting setup with Plesk and My App Server, you can combine log reading with service control, Java version selection, and Tomcat management to resolve problems faster and with less guesswork. Focus on the first meaningful error, compare application and container logs, and use timestamps to connect the failure with the action that triggered it.
If you keep this methodical approach, most Java hosting issues become much easier to understand, explain, and fix.