How to troubleshoot missing Suricata alerts

A silent Suricata sensor is easiest to diagnose when the expected alert is tied to one packet capture and one signature ID. An alert can be missing even though the engine starts cleanly if the packet never reaches the rule, the rule file is not loaded, or the match is written to a log path that nobody is reading.

An offline pcap replay keeps each pass tied to the same payload instead of changing live traffic. Use a new log directory for each replay so an empty fast.log or eve.json result means the current run stayed silent, not that older output was overlooked.

Start with rule loading before changing HOME_NET, thresholds, suppression, or downstream log ingestion. When suricata -T reports that no rules were loaded, repair the active ruleset first; when the expected signature loads but the replay still stays silent, continue with rule direction, variable, or suppression checks.

Steps to troubleshoot missing Suricata alerts:

Create a new log directory for the replay.
```
$ sudo mkdir /tmp/suricata-alert-check
```
Use a new path for every replay, or remove the old directory only after saving any logs that still matter.

Replay the capture with the active Suricata configuration.

$ sudo suricata -c /etc/suricata/suricata.yaml -r /tmp/missing-alert.pcap -l /tmp/suricata-alert-check -k none
i: suricata: This is Suricata version 8.0.3 RELEASE running in USER mode
W: detect: 1 rule files specified, but no rules were loaded!
i: threads: Threads created -> RX: 1 W: 8 FM: 1 FR: 1   Engine started.
i: suricata: Signal Received.  Stopping engine.
i: pcap: read 1 file, 1 packets, 136 bytes

-k none avoids checksum-offload noise when replaying captures from another host. Replace /tmp/missing-alert.pcap with a capture that contains traffic expected to trigger the missing alert.
Related: How to test Suricata with pcap replay

Confirm that the replay wrote no fast.log alert.
```
$ sudo wc -c /tmp/suricata-alert-check/fast.log
0 /tmp/suricata-alert-check/fast.log
```
A zero-byte fast.log from a fresh output directory means this replay did not generate a fast alert.

Test the active configuration and rule loading path.

$ sudo suricata -T -c /etc/suricata/suricata.yaml
i: suricata: This is Suricata version 8.0.3 RELEASE running in SYSTEM mode
W: detect: 1 rule files specified, but no rules were loaded!
i: suricata: Configuration provided was successfully loaded. Exiting.

A clean configuration parse is not enough when the rule count is zero; Suricata can parse the YAML while still having no loaded signatures to alert on.
Related: How to test Suricata configuration

Update the managed ruleset when the active rule file is missing or empty.

$ sudo suricata-update
25/6/2026 -- 07:19:11 - <Info> -- No sources configured, will use Emerging Threats Open
25/6/2026 -- 07:19:11 - <Info> -- Fetching https://rules.emergingthreats.net/open/suricata-8.0.3/emerging.rules.tar.gz.
##### snipped #####
25/6/2026 -- 07:19:18 - <Info> -- Writing rules to /var/lib/suricata/rules/suricata.rules: total: 66793; enabled: 50866; added: 66793; removed 0; modified: 0
25/6/2026 -- 07:19:18 - <Info> -- Testing with suricata -T.
25/6/2026 -- 07:19:23 - <Info> -- Done.

suricata-update writes the default compiled rules file used by packaged Suricata configurations. Use a local rule file instead only when the missing alert belongs to a private signature.
Related: How to update Suricata rules

Validate that the repaired configuration loads rules.

$ sudo suricata -T -c /etc/suricata/suricata.yaml -v
Notice: suricata: This is Suricata version 8.0.3 RELEASE running in SYSTEM mode
Info: detect: 1 rule files processed. 50866 rules successfully loaded, 0 rules failed, 0 rules skipped
Info: threshold-config: Threshold config parsed: 0 rule(s) found
Info: detect: 50871 signatures processed. 1285 are IP-only rules, 4505 are inspecting packet payload, 44845 inspect application layer, 110 are decoder event only
Notice: suricata: Configuration provided was successfully loaded. Exiting.

Restart or reload the live service before waiting for new interface traffic; offline pcap runs read the repaired rules when the replay command starts.
Related: How to manage the Suricata service

Create a clean log directory for the retest.
```
$ sudo mkdir /tmp/suricata-alert-fixed
```

Replay the same capture after repairing rule loading.

$ sudo suricata -c /etc/suricata/suricata.yaml -r /tmp/missing-alert.pcap -l /tmp/suricata-alert-fixed -k none
i: suricata: This is Suricata version 8.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 8 FM: 1 FR: 1   Engine started.
i: suricata: Signal Received.  Stopping engine.
i: pcap: read 1 file, 1 packets, 136 bytes

Confirm that fast.log contains the expected alert.
```
$ sudo cat /tmp/suricata-alert-fixed/fast.log
06/25/2024-08:00:00.000000  [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 198.51.100.20:40000 -> 192.0.2.10:80
```
If the rule count is nonzero but the same capture still produces no alert, inspect HOME_NET direction, signature suppression, and alert thresholds before changing log ingestion.
Related: How to configure Suricata HOME_NET
Related: How to suppress a Suricata signature ID
Related: How to configure Suricata alert thresholds

Confirm the same alert in eve.json when downstream tools read EVE.

$ sudo jq -c 'select(.event_type=="alert") | {signature:.alert.signature,signature_id:.alert.signature_id,src_ip,dest_ip}' /tmp/suricata-alert-fixed/eve.json
{"signature":"GPL ATTACK_RESPONSE id check returned root","signature_id":2100498,"src_ip":"198.51.100.20","dest_ip":"192.0.2.10"}