The panel does not change the Falco config — it only shows the snippet and commands you apply on the server over SSH.
# /etc/falco/rules.d/local-tuning.yaml - rule: <EXACT RULE NAME from the list above> condition: and not fd.name = /path/to/exclude append: true
sudo nano /etc/falco/rules.d/local-tuning.yaml sudo falco --validate /etc/falco/rules.d/local-tuning.yaml sudo systemctl restart falco 2>/dev/null || sudo systemctl restart falco-modern-bpf
Use the exact rule name. If the list shows the message text instead of a name, enable JSON output in falco.yaml (json_output: true) so the dashboard receives exact rule names.
Falco is usually discussed as a Kubernetes tool, and most of what is written about it assumes a cluster. It works perfectly well on an ordinary Linux server, where it watches system calls and raises an alert when a process does something it has no business doing — spawning a shell from a web server, writing to a system binary directory, reading sensitive files, opening an unexpected outbound connection.
This page shows the alerts with their priority, the rule that fired, and the process and command line behind them. That last detail is what makes Falco different from log-based tools: it reports what a process actually did, not what a service chose to write about it.
The default rule set is written with containers in mind and will be noisy on a bare server until it is tuned. Package managers, backup jobs and cron scripts routinely trip rules meant to catch intruders. Budget an hour or two of silencing legitimate behaviour before the output becomes something you can act on — an alert stream nobody reads is the same as no alerting at all.