Inactive Remediation Components warning despite active bouncer

[serene cedar]

Important Information

Thank you for getting in touch with your support request. To expedite a swift resolution, could you kindly provide the following information? Rest assured, we will respond promptly, and we greatly appreciate your patience. While you wait, please check the links below to see if this issue has been previously addressed. If you have managed to resolve it, please use run the command /resolve or press the green resolve button below.

Log Files

If you possess any log files that you believe could be beneficial, please include them at this time. By default, CrowdSec logs to /var/log/, where you will discover a corresponding log file for each component.

Guide Followed (CrowdSec Official)

If you have diligently followed one of our guides and hit a roadblock, please share the guide with us. This will help us assess if any adjustments are necessary to assist you further.

Screenshots

Please forward any screenshots depicting errors you encounter. Your visuals will provide us with a clear view of the issues you are facing.

© Created By WhyAydan for CrowdSec ❤️ · Nov 12, 2025, 2:34 PM

[winged leaf]

within the output of cscli bouncers list are there any other entries?

[winged leaf]

Hey @crude stone you can see your console says 3 remediation and inside the output you have

 fw-bouncer                                  ✔️                                                                                                                            api-key

which has no timestamp thats the reason the alert is triggering.

If you click on the engine name itself WOWHOST it would show you the engine details which outlines which name within the bouncers list is not reporting as in use.

if this is not in use simply run cscli bouncers delete fw-bouncer and within the next metrics push the console will remove the warning about inactive components

We are rolling out new feature in the next month to better aid new users when it comes to troubleshooting issues.

the question is very vauge and impossible to answer without any context. You have alerts triggering so crowdsec is monitoring logs and triggering alerts.

Have you tried a small decision on your WAN to ensure blocking works?

cscli decisions add --ip <your_wan> -d 2m

adds a ban decision to your ip for 2 minutes so you can regain access afterwards

Forgot to mention once you add a decision, you should try to access whichever services you are protecting

Yeah so overall looks healthy, check cscli metrics for the acquisition section this outlines which files it monitoring and if you have a service which wasnt detected and you want to add then following the post installation guides is the most informative places

https://docs.crowdsec.net/u/getting_started/next_steps

within the cscli metrics you can see all the active decisions

yeah so these are currently active

╭────────────────────────────────────────────────────────────────╮
│ Local API Decisions                                            │
├───────────────────────────────────┬──────────┬─────────┬───────┤
│ Reason                            │ Origin   │ Action  │ Count │
├───────────────────────────────────┼──────────┼─────────┼───────┤
│ database:bruteforce               │ CAPI     │ ban     │ 7     │
│ http:bruteforce                   │ CAPI     │ ban     │ 591   │
│ http:crawl                        │ CAPI     │ ban     │ 27    │
│ http:scan                         │ CAPI     │ ban     │ 13891 │
│ crowdsecurity/dovecot-spam        │ crowdsec │ ban     │ 1     │
│ crowdsecurity/http-probing        │ crowdsec │ ban     │ 1     │
│ otx-webscanners                   │ lists    │ ban     │ 2559  │
│ ftp:bruteforce                    │ CAPI     │ ban     │ 40    │
│ http:exploit                      │ CAPI     │ ban     │ 84    │
│ pop3/imap:bruteforce              │ CAPI     │ ban     │ 592   │
│ ssh:bruteforce                    │ CAPI     │ ban     │ 315   │
│ crowdsecurity/http-bad-user-agent │ crowdsec │ ban     │ 10    │
│ crowdsec_cve_2024_4577            │ lists    │ ban     │ 1369  │
│ firehol_greensnow                 │ lists    │ captcha │ 6254  │
╰───────────────────────────────────┴──────────┴─────────┴───────╯

Well do you have apache infront of litespeed or litespeed infront of apache?

the problem with monitoring multiple web servers on the same machine means duplicate requests will be logged as it goes through the proxy chain.

so if litespeed is first then you should only monitor litespeed logs only as a single request may be poured multiple times to scenarios as it believes each log per each proxy is not linked.