Where to find JSP related logs in Plesk

When you are troubleshooting a JSP site in Plesk, the first place to look is usually the web server logs for the domain and, if your hosting package includes Java hosting through My App Server, the Tomcat or application-specific logs for the private JVM. In practice, JSP issues can appear in more than one log source at the same time: Apache may record the request, Tomcat may record the JSP compilation or servlet error, and the application itself may write additional details.

Finding the right log quickly helps you identify whether the problem is caused by a missing file, a deployment issue, a Java exception, a permissions problem, or a web server configuration error. In a Plesk hosting environment, log locations depend on the domain, the application type, and whether you are using standard web hosting or a Java/Tomcat setup.

Where JSP-related logs are usually stored in Plesk

In most Plesk setups, JSP-related logs are found in one or more of the following places:

Domain web logs — Apache or nginx request logs for the website.
Tomcat logs — if the site runs on a private Tomcat instance or Java service.
Application logs — logs produced by your JSP application, framework, or custom code.
Plesk event and system logs — useful for service start/stop issues and control panel actions.

If you are using ITA Java hosting with My App Server, you should also check the logs related to the service itself, because JSP pages may be processed by your own Apache Tomcat or private JVM rather than by a shared server-side setup. That means the key error message may not appear only in the domain access log.

Check the domain logs in Plesk first

For many JSP problems, the quickest starting point is the domain log viewer in Plesk. This is where you can see request entries, HTTP status codes, and basic server-side errors for the website.

How to open the domain logs

Sign in to Plesk.
Open Websites & Domains.
Select the domain that hosts your JSP application.
Click Logs or Log Browser, depending on the Plesk version and theme.

In the log viewer, look for:

500 errors, which often indicate application exceptions or server-side failures.
404 errors, which may mean the JSP file, route, or deployment path is wrong.
403 errors, which may point to permissions or access restrictions.
JSP compilation messages, if the request reached Tomcat and the page failed to compile.

The domain logs are useful because they confirm whether the request reached the web server and how the request was handled before it was passed to Java or Tomcat.

Typical log file paths for JSP sites

Depending on your hosting setup, the physical log files may be stored in one or more of these locations on the server:

/var/www/vhosts/system/your-domain.com/logs/
/var/www/vhosts/your-domain.com/logs/
/var/log/ for system-wide service logs
Tomcat-specific log directories configured for the service

Common file names can include:

access_log or access.log
error_log or error.log
proxy_error.log
catalina.out
catalina.<date>.log
localhost.<date>.log
manager.<date>.log

Exact file names depend on the server configuration and how the Java service was installed. If you are not sure where the logs are stored, use the Plesk log browser first, then ask support for the exact path if needed.

Where to find Tomcat logs for JSP hosting

If your JSP application runs through Apache Tomcat, the most relevant files are usually the Tomcat runtime logs. These logs often contain the actual Java exception, stack trace, compilation failure, or deployment warning that explains the issue.

Most useful Tomcat log files

catalina.out — general Tomcat output and startup/shutdown messages.
catalina.<date>.log — detailed runtime messages for a specific day.
localhost.<date>.log — web application-specific errors, including JSP compilation problems.
manager.<date>.log — manager application events, if used.
host-manager.<date>.log — host manager events, if used.

These logs are especially important when:

a JSP page throws a Java exception;
the application fails during deployment;
the servlet container cannot compile the JSP file;
the JVM fails to start correctly;
the application behaves differently from the web server access logs.

In a managed hosting environment with a private Tomcat instance, Tomcat logs are often the fastest way to diagnose Java-level problems. Plesk may show the domain request, but the Java exception is usually recorded in the Tomcat log.

Using My App Server logs in ITA Java hosting

If your hosting account uses My App Server, your JSP application can run with its own managed Apache Tomcat or private JVM. This means the logs may be separated from the default web hosting logs, which is helpful for keeping Java applications isolated and easier to troubleshoot.

With My App Server, pay attention to these log sources:

Service logs for the Java application server instance.
Tomcat logs for startup, runtime, and JSP compilation problems.
Domain logs in Plesk, which show HTTP requests and response codes.
Application logs created by your own JSP or servlet application.

If your site uses a custom Java version or a manually uploaded application server, the log path may be different from a standard Tomcat layout. In that case, check the service configuration inside Plesk or use the service control options to inspect the instance status and recent output.

How to locate logs in Plesk for a JSP site step by step

If you need to troubleshoot a JSP error and do not know which log to use, follow this practical sequence.

Step 1: Open the domain log viewer

Go to Websites & Domains, select the domain, and open Logs. This gives you immediate visibility into recent HTTP activity and error codes.

Step 2: Reproduce the issue

Refresh the JSP page or repeat the action that causes the problem. This makes it easier to find the exact moment the error appears in the logs.

Step 3: Filter by time and status code

Look for entries that match the time of the error. Focus on:

5xx responses for server-side failures;
4xx responses for access or path issues;
requests to the JSP file, servlet endpoint, or application path;
POST requests if the problem happens after a form submission.

Step 4: Check the Tomcat logs

If the domain log only shows that an error occurred, open the Tomcat logs. Search for:

SEVERE
Exception
Caused by
JSP
Compilation
ClassNotFoundException

The first real error line is often more useful than the stack trace that follows. Read upwards from the exception to understand what triggered it.

Step 5: Compare the log timestamp with your deploy time

If the issue started after a deployment, the logs may show a missing class, a bad configuration file, or a failed unpacking process. Many JSP issues appear immediately after a WAR upload, version change, or update to the Java runtime.

What different log messages usually mean

Understanding the message helps you decide whether the problem is in the web server, the application, or the Java runtime.

404 Not Found

The requested JSP file or route may be wrong, the file may not be deployed, or the app context path may be incorrect.

403 Forbidden

This usually points to file permissions, access rules, or a protected directory. In some cases, the app server can reach the file, but Apache denies access.

500 Internal Server Error

A 500 response often means the request reached the server but failed during processing. For JSP hosting, this is commonly caused by a Java exception, missing class, failed JSP compilation, or an application configuration problem.

JSP compilation errors

These may mention syntax errors in the JSP file, missing imports, incompatible Java code, or a problem with libraries on the classpath.

ClassNotFoundException or NoClassDefFoundError

The application is trying to load a class that is not available in the deployed environment. This is common after uploading a WAR file without all required dependencies.

OutOfMemoryError

The Java process may be running out of memory. In shared hosting or small private JVM setups, this can happen when the application is too large or improperly configured.

Check application-specific logs if the JSP framework writes its own output

Many JSP applications use frameworks or custom logging libraries that write their own files. If the domain and Tomcat logs do not show enough detail, check your application logs as well.

Examples include:

framework logs from Spring-based applications;
custom log files configured in the app;
logs under the application’s WEB-INF structure, if the app writes there;
logs stored in a dedicated logs directory inside the deployment package.

Application logs are particularly useful when the problem is logical rather than technical, such as authentication failure, a broken database query, or invalid input handling.

How to use logs safely and effectively

Logs often contain sensitive data such as usernames, request paths, internal IPs, or exception details. Handle them carefully, especially if you are sharing them with support.

Do not publish full logs publicly.
Share only the relevant time range if possible.
Remove passwords, tokens, and personal data.
Include the exact URL and time of the error when asking for help.

For troubleshooting, it helps to gather:

the domain name;
the exact JSP page or application action;
the approximate time of the error;
the HTTP status code if visible;
the full exception message from the Tomcat log.

JSP logging tips for better diagnostics

If you administer the application, you can make future troubleshooting easier by improving logging in the app itself.

Use meaningful log levels

Enable enough detail for troubleshooting, but avoid excessive debug output in normal operation. A balanced approach makes the logs easier to read.

Log startup and deployment events

Record when the application starts, redeploys, connects to the database, or loads configuration files. These messages are useful when a JSP issue appears after a restart or publish action.

Include correlation details

If your app handles user requests, include request IDs or transaction references in logs where appropriate. This helps connect the browser error with the server-side event.

Keep time settings consistent

Make sure the server time zone and application timestamps are aligned. If timestamps differ, diagnosing a JSP issue becomes more difficult.

Common troubleshooting workflow for JSP hosting in Plesk

Here is a practical workflow that works well in most Plesk-based hosting environments:

Open the Plesk domain logs.
Reproduce the error in the browser.
Check the HTTP status code.
Open the Tomcat logs for the same time period.
Look for Java exceptions, JSP compilation problems, or class loading errors.
Review application logs if the server logs are not enough.
Verify file permissions, deployment path, Java version, and restart status if needed.

This approach usually narrows the issue down quickly, especially when you are working with a managed hosting account and a private Java service inside Plesk.

When to contact support

Contact hosting support if you cannot access the log files, if the Java service will not start, or if the same error repeats after you have verified the application code and deployment package. Support can usually help confirm the exact log location, service status, and whether the issue is related to the Tomcat instance, the Java runtime, or the domain configuration.

It is helpful to send support:

the domain name;
the time the issue happened;
the JSP or servlet URL;
the relevant log lines;
what changed before the issue started.

FAQ

Where do I find JSP logs in Plesk?

Start with the domain log viewer in Websites & Domains. If the site runs on Tomcat or My App Server, also check the Tomcat or Java service logs, because the detailed error is often recorded there.

Why do I see a 500 error but no clear message in the domain log?

The web server log may only show the request failure. The actual Java exception is often written to the Tomcat log, such as catalina.out or a dated localhost log.

Can JSP compilation errors appear in Apache logs?

Sometimes the Apache or nginx logs show the failed request, but the compilation details are usually in the Tomcat logs. That is why you should always check both sources.

What if my hosting uses a private JVM through My App Server?

Then the relevant logs are usually tied to that specific service instance. Check the domain logs first, then the Java service logs and Tomcat logs for the private JVM.

How can I tell whether the issue is in Apache or Tomcat?

If the log shows a normal HTTP request but no Java exception, the issue may be in Apache, proxying, or access rules. If you see a stack trace, JSP compilation failure, or SEVERE Java message, the issue is usually in Tomcat or the application layer.

Do I need access to the server shell to find JSP logs?

Not always. Many useful logs are available in Plesk’s log viewer. Shell access is only needed if you must inspect files directly or investigate deeper service-level issues.

Conclusion

For JSP hosting in Plesk, the best place to find related logs is usually the domain log viewer first, followed by the Tomcat or private Java service logs if your application runs through My App Server. Domain logs show the request and response, while Tomcat logs usually reveal the actual Java or JSP error. In a managed hosting setup, checking both sources gives you the clearest path to diagnosing compilation issues, deployment problems, access errors, and runtime exceptions.

When troubleshooting, always match the log timestamp with the moment the error occurred, then review the exact exception line before reading the rest of the stack trace. This simple workflow saves time and makes JSP diagnostics in Plesk much more effective.

Where to find JSP-related logs in Plesk