Personal note: This technical note reflects practical QRadar troubleshooting experience and summarizes IBM Support guidance. Confirm the procedure against your installed QRadar version and follow your change-control process.
A stopped Tomcat service, a full filesystem, or a failed backend dependency requires root-cause investigation. Deleting cached JSP files does not fix those underlying conditions.
1. Identify the symptom
Separate a browser-specific problem from a Console-side failure before changing backend files.
- If only one user is affected, try a private/incognito window or another supported browser. If that works, clear the browser cache and retry.
- If the GUI is unavailable for all users, or Tomcat is down, start with backend service and resource checks.
- If the page loads but a specific UI component is slow or missing, browser testing and backend logs can help narrow the scope.
2. Check the backend first
Run these read-only checks on the QRadar Console. Record the output and timestamp before restarting services or deleting files.
systemctl status tomcat --no-pager
systemctl --failed
df -hT / /store
journalctl -u tomcat -n 100 --no-pager| Finding | Next action |
|---|---|
| Tomcat is inactive or failed | Review service logs and dependencies. Do not assume cache corruption is the cause. |
/ or /store is critically full | Investigate storage usage and resolve the underlying space issue using the procedure for your QRadar version. Do not start with cache cleanup. |
| Tomcat is active, but the UI is slow or a component fails to load | Check browser behavior, resource pressure, and relevant QRadar logs. Consider cache cleanup only when support guidance and symptoms justify it. |
Stopping or restarting Tomcat makes the QRadar UI unavailable during the operation and ends active UI sessions. Use an approved maintenance window when required by your change policy.
3. When Tomcat cache cleanup is appropriate
IBM documents this procedure for cases where the QRadar UI is slow or specific components do not load as expected. IBM Support may recommend clearing Tomcat's cached JSP files after initial troubleshooting.
Do not use it as the first response to an unreachable GUI when Tomcat is stopped, storage is exhausted, or another backend service has failed. Resolve that condition first or work with IBM Support.
4. Clear the Tomcat JSP cache
Use this procedure only when it is appropriate for your QRadar release and approved for your environment. Confirm that /store has enough free space for the backup and that the source directory exists.
- SSH to the QRadar Console as
rootthrough your approved administration path. - Create the support backup directory:
mkdir -p /store/ibm_support- Stop Tomcat and confirm that it has stopped:
systemctl stop tomcat
systemctl status tomcat --no-pager- Back up the cached JSP directory. If the copy fails, stop here and do not run the removal command.
cp -pr /opt/tomcat/work/Catalina/localhost/console/org/apache/jsp /store/ibm_support/- Only after confirming the backup succeeded, remove the cached JSP files:
rm -rfv /opt/tomcat/work/Catalina/localhost/console/org/apache/jsp- Start Tomcat and confirm its state:
systemctl start tomcat
systemctl status tomcat --no-pagerThe rm -rfv command permanently removes the specified directory. Verify the full path, stop Tomcat first, and confirm the backup exists before running it. Run commands one at a time; do not paste the block as an unattended script.
5. Validate recovery
- Confirm Tomcat is active and check for startup errors.
- Open QRadar in a private/incognito browser session and test the affected pages or components.
- If the UI remains unavailable, do not repeat cache deletion blindly. Recheck service dependencies, disk space, and logs, then continue with IBM Support.
6. Field lesson
During a previous QRadar GUI outage, backend checks showed Tomcat was stopped while /store was full. The recovery priority was to investigate service state and storage exhaustion—not to treat the incident as a cache-only problem.
The operational sequence is: confirm scope → inspect services and disk → review logs → apply a targeted fix → validate the UI.
7. IBM references
- IBM Support — Clear Tomcat Cache to Fix Slow or Unresponsive QRadar User Interface
- IBM Support — Diagnose slow QRadar UI response caused by CPU or memory pressure
- IBM Support — Troubleshoot QRadar disk-space issues and service failures
Verify these commands and paths against your installed QRadar release and IBM Support procedure before making changes.
Backend troubleshooting, service recovery, and SIEM operations
For QRadar UI failures, Tomcat recovery, or related backend issues, contact me using one of the links below.