Security Engine No Alerts
The Engine No Alerts issue appears when your Security Engine has been running but hasn't forwarded any alerts to the Central API in the last 48 hours.
What Triggers This Issue
- Trigger condition: No alerts generated for 48 hours
- Criticality: ⚠️ High
- Impact: Your detection system may not be working as expected
Common Root Causes
- Appropriate collections not installed: Make sure you have detection scenarios and/or AppSec rules that cover your services
- Events massively whitelisted: Due to misconfiguration, proxying issues, or faulty custom whitelisting
- Scenarios in simulation mode: Detection scenarios are installed but set to simulation mode, preventing actual alerts.
- Legitimate low-activity environment: Your proactive defenses might be good enough that you don't detect additional malicious behaviors (CrowdSec blocklists or other protections may already deflect all malicious activity)
Other Issues
- 🔗 No logs being read: The acquisition configuration may be missing, disabled, or pointing to empty log sources.
- 🔗 No logs being parsed: Logs are being read but parsers can't process them due to format mismatches or missing collections.
Diagnosis & Resolution
If it is not due to other issues, use the diagnosis and resolutions below.
Appropriate collections not installed
🔎 Check installed collections match your services
Verify you have collections matching your protected services:
sudo cscli collections list
Run this command for Docker or Kubernetes
docker exec crowdsec cscli collections list
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli collections list
Compare your installed collections against your actual services (nginx, apache, ssh, etc.). Missing collections means no detection rules for those services.
You can try to run a test on your logs to spot issues. See the cscli explain documentation
🛠️ Install required collections for your services
Visit the CrowdSec Hub to find collections for your stack by browsing or searching. A collection bundles parsers and scenarios for a given service. For example, the NGINX collection includes NGINX parsers and scenarios for common HTTP attacks.
Collections are packaged for various type of services:
- Web servers:
crowdsecurity/nginx,crowdsecurity/apache2,crowdsecurity/caddy - SSH:
crowdsecurity/sshd - Linux base:
crowdsecurity/linux - AppSec/WAF:
crowdsecurity/appsec-*collections for application-level protection
Install collections using:
sudo cscli collections install crowdsecurity/nginx
sudo systemctl reload crowdsec
Run this command for Docker or Kubernetes
Docker
docker exec crowdsec cscli collections install crowdsecurity/nginx
docker restart crowdsec
Kubernetes
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli collections install crowdsecurity/nginx
kubectl rollout restart deployment/crowdsec -n crowdsec
Events massively whitelisted
Misconfigured whitelists can cause alerts to be ignored.
🔎 Check whitelisting metrics
Check whether many (or all) lines are being whitelisted.
sudo cscli metrics show acquisition
Run this command for Docker or Kubernetes
Docker
docker exec crowdsec cscli metrics show scenarios
Kubernetes
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli metrics show scenarios
Look at the Lines whitelisted column
╭────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ Acquisition Metrics │
├───────────────────────┬──────────────┬────────────────┬────────────────────────┬───────────────────┤
│ Source │ Lines read │ Lines parsed │ Lines unparsed │ Lines poured to bucket │ Lines whitelisted │
├──────────┼────────────┼──────────────┼────────────────┼────────────────────────┼───────────────────┤
│ file:... │ 743 │ 635 │ 108 │ - │ 185 │
╰──────────┴────────────┴──────────────┴────────────────┴────────────────────────┴───────────────────╯
🛠️ Make sure the IP in your logs are public IPs
Due to misconfiguration or log source choice, source IPs can be private/internal addresses instead of X-Forwarded-For client IPs.
Look at your log files and make sure any proxy in front of your service provides X-Forwarded-For source IPs.
🛠️ Review and adjust your custom whitelist configuration
If you create custom whitelist configuration via s02-enrich, make sure it does not discard legitimate alerts.
Check our whitelisting documentation.
Scenarios in simulation mode
🔎 Check if scenarios are in simulation mode
Verify whether your scenarios are set to simulation mode:
sudo cscli simulation status
Run this command for Docker or Kubernetes
Docker
docker exec crowdsec cscli simulation status
Kubernetes
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli simulation status
If scenarios are listed, they are in simulation mode and are not sent to CrowdSec Console (they should still appear in cscli alerts list).
🛠️ Disable simulation mode to generate alerts
Disable simulation mode to allow alerts to be generated:
sudo cscli simulation disable --all
sudo systemctl reload crowdsec
Run this command for Docker or Kubernetes
Docker
docker exec crowdsec cscli simulation disable --all
docker restart crowdsec
Kubernetes
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli simulation disable --all
kubectl rollout restart deployment/crowdsec -n crowdsec
You can also disable simulation for specific scenarios only:
sudo cscli simulation disable crowdsecurity/ssh-bf
sudo systemctl reload crowdsec
Legitimate low-activity environment
If you have protection measures in front of your services, they may already block unwanted traffic.
Given background internet noise, publicly exposed services usually still receive reconnaissance traffic, but CrowdSec blocklists may already block most malicious traffic.
Let’s check.
🔎 Check traffic volume being processed
Check how much traffic your service is processing:
sudo cscli metrics show acquisition parsers
Run this command for Docker or Kubernetes
Docker
docker exec crowdsec cscli metrics show acquisition parsers
Kubernetes
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli metrics show acquisition parsers
Look at "Lines parsed" - if this number is very low (dozens or hundreds per day), you may simply have insufficient traffic volume for malicious activity to appear.
🔎 Check if blocklists are blocking threats upstream
Check whether proactive defenses are blocking threats upstream. You can do this with cscli or Console remediation metrics if you have a compatible bouncer.
sudo cscli decisions list
sudo cscli metrics show bouncers
Run this command for Docker or Kubernetes
Docker
docker exec crowdsec cscli decisions list
docker exec crowdsec cscli metrics show bouncers
Kubernetes
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli decisions list
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli metrics show bouncers
High numbers of active decisions or bouncer blocks may indicate proactive defenses are already blocking malicious actors. Still verify that no other issue exists.
Related Issues
- Log Processor No Logs Read - If acquisition is not working
- Log Processor No Logs Parsed - If parsing is failing
- Security Engine Troubleshooting - General Security Engine issues
Getting Help
If you've verified logs are being read and parsed correctly but still see no alerts:
