QRadar troubleshooting:
a practical checklist

1. Start with the symptom and scope

Before using a support script, define what is failing: SSH access, managed-host communication, a failed deploy, an application, missing events, high event rates, or a patch/upgrade. Note when it began, which hosts are affected, recent changes, and the exact error from the UI or logs.

In a distributed deployment, distinguish the Console from the affected managed host. A local check on the Console will not necessarily validate every Event Collector, Event Processor, App Host, or other host.

2. Capture a basic system baseline

Record the installed QRadar version and patch information on the host being investigated. IBM's QRadar support-tool reference documents the following:

/opt/qradar/bin/myver -v

For a deployment inventory, IBM documents deployment_info.sh with the -OS option. The original note used -OH; use the option documented for your installed version and check the script's help if the output differs.

/opt/qradar/support/deployment_info.sh -OS

The all_servers.sh tool can issue commands across multiple QRadar appliances. Review its usage before running it, and avoid broad commands unless you understand the impact and target set.

/opt/qradar/support/all_servers.sh -h

3. QRadar support-tool quick reference

These commands are useful starting points for common checks. Tool availability and options vary by QRadar release; confirm the syntax in the installed tool's help and IBM's QRadar Support Tools 101 reference.

Network capture: narrow the filter and limit the capture

If you suspect a syslog path issue, confirm the actual interface and capture only the relevant endpoint/port with a packet limit:

tcpdump -nn -i any host 192.0.2.10 and port 514 -c 10

Replace 192.0.2.10 with the actual endpoint and add udp or tcp only when appropriate. Avoid broad, unbounded captures; packet payloads may contain sensitive event content.

4. Check connectivity and service status

SSH connectivity

If the symptom is an SSH connection issue, run a verbose connection attempt from the system initiating the SSH session and replace the placeholders with the actual account and host:

ssh -vv user@managed-host.example

The verbose output can help distinguish DNS, routing, host-key, authentication, and connection failures. Do not paste private keys, passwords, tokens, or unredacted host details into public logs or issue reports.

HostContext status

On the affected QRadar host, check whether HostContext is active:

systemctl status hostcontext

For service logs, the standard system journal can help identify a start failure or repeated errors:

journalctl -u hostcontext

Use a bounded time range if the journal is large, and compare the timestamps with the incident. A running service does not guarantee the entire QRadar deployment or data pipeline is healthy.

5. Verify filesystem capacity

Low disk space can interrupt updates, deployment tasks, log processing, and other operations. Start by reviewing filesystem type, capacity, and usage:

df -hT
df -h /storetmp /var/log

Look closely at the partitions relevant to the symptom, and compare the result to the sizing and support guidance for your QRadar version. Do not delete logs, data, or backup files without identifying their purpose and following a safe cleanup procedure.

6. Validate deployment consistency

If deploy changes time out, managed hosts disagree with the Console, or deployment status is inconsistent, IBM documents validate_deployment.sh as a tool for finding discrepancies between deployment configuration and database entries.

/opt/qradar/support/validate_deployment.sh -h

Review the supported usage for your version, then run the validation procedure as documented. Record the output and investigate reported inconsistencies rather than editing /opt/qradar/conf/deployment.xml or database records manually.

The file below is worth checking when investigating certain deploy-timeout cases, but its presence alone is not permission to remove it:

ls -l /opt/qradar/conf/hostcontext.NODOWNLOAD

7. Review logs and collect evidence

Start with the timestamp of the failure and the logs relevant to the operation. Common locations from the original checklist include:

• /var/log/qradar.log — QRadar application and system messages.
• /var/log/qradar.error — error messages, when present on the installed release.
• /var/log/setup/<build-id>/patches.log — setup/patch output for the matching build identifier, if applicable.

For a quick, bounded view of recent QRadar messages:

tail -n 200 /var/log/qradar.log

For log collection, check the currently supported options first:

/opt/qradar/support/get_logs.sh -h

Use IBM's supported log-collection process for the installed release and the scope of the case. Sanitize collected logs before sharing them externally; they can contain usernames, IP addresses, hostnames, domains, or other sensitive operational data.

8. Applications and WinCollect

QRadar applications

If an app preview, install, uninstall, or runtime task is failing, use the UI and the diagnostic tools supported by the installed QRadar version. Recon can help inspect application containers on supported Console/App Host deployments; on QRadar 7.5.x, consult the relevant IBM guidance for checking application state. Avoid direct SQL updates to application tables unless IBM Support has provided a version-specific procedure.

Related: QRadar health checks with DrQ, Recon, and Cliniq.

WinCollect

If the issue is limited to managed WinCollect agents, start with agent status and log-source communication, then use the supported WinCollect health-check utility where available:

/opt/qradar/support/WinCollectHealthCheck.sh -h

Utility availability and options vary by release and deployment model. Use the help output and current IBM instructions before running the check.

9. Event pipeline and EPS symptoms

For delayed or missing events, isolate three stages: source transmission, QRadar receipt, and searchability. Check the affected log source in the UI, the source-to-QRadar network path, QRadar messages around the incident, and the event-pipeline metrics documented for your release.

Some older troubleshooting notes use direct JMX commands, hard-coded ports, or service-specific query strings to inspect EPS and event ingress. Those commands can be version- and service-dependent; the one-line command in the original note also combined two commands incorrectly. Do not paste it into production unchanged. Use the IBM support-tool reference or a version-specific support procedure to identify the correct diagnostic for the host and service under investigation.

For network-related managed-host problems, use supported interface and connection checks and follow the appropriate IBM networking guidance rather than assuming every symptom is an EPS issue.

10. Commands from older notes that need special handling

Older notes included internal database queries, direct JMX calls, hard-coded ports, or token-file checks. These are not reliable generic first-line tests: schemas and service interfaces change, and tokens are sensitive. Prefer the supported UI/API or the IBM diagnostic procedure for the specific symptom and release. Never edit QRadar database records or deployment files manually unless IBM Support provides a version-specific instruction.

11. Official references

• IBM QRadar Support Tools 101
• IBM Support: validate_deployment.sh
• IBM Support: deploy changes that do not complete
• IBM Support: QRadar network troubleshooting commands
• IBM QRadar: upgrade preparation checklist

Command availability and paths vary by QRadar release. During production outages or patching, preserve evidence and follow the approved change process or IBM Support procedure.