A Linux host shows the Falcon sensor consuming significant CPU:
PID USER %CPU %MEM COMMAND
2841 root 87.3 1.2 falcon-sensor-bpf
On Windows the same situation appears as CSFalconService sitting high in Task Manager. In both cases the sensor is usually working exactly as designed — the question is what it is working on.
Nothing in this guide asks you to uninstall or permanently disable the sensor. Where a step temporarily reduces protection, that is called out explicitly.
Why This Happens
The Falcon sensor observes process execution, file operations and network activity. Its CPU cost is therefore a function of how many such events the host generates. Sustained high usage almost always traces to one of these:
- A genuinely high-churn workload. Build servers, CI runners, container hosts, backup windows, log processors and database servers create enormous volumes of file and process events. The sensor is doing proportional work.
- A recent kernel or sensor change. On Linux the sensor can run in kernel mode or user mode (eBPF), and their performance characteristics differ. A kernel update that changes which backend is in use can change CPU profile on an unchanged workload.
- The sensor is in Reduced Functionality Mode, or repeatedly trying to recover from a degraded state.
- A pathological interaction — a filesystem with millions of small files being repeatedly walked, a runaway process spawning continuously, or a monitoring agent scanning the same tree in a loop.
- An outdated sensor carrying a known performance issue fixed in a later version.
The useful framing: high CPU is a symptom of event volume. Find the volume before you change the sensor.
Fix 1: Establish What the Sensor Is Reacting To
Look at the host before touching the sensor. What else is busy?
top -b -n 1 | head -20
Then find what is generating process churn — a process spawning thousands of short-lived children is a classic cause:
# Watch process creation rate
vmstat 1 5
# Count processes by parent
ps -eo ppid,comm --no-headers | sort | uniq -c | sort -rn | head -10
And what is generating file activity:
sudo iotop -o -b -n 3 2>/dev/null | head -20
If a build, backup, antivirus scan, log rotation or container churn lines up with the sensor's CPU, you have your answer, and the fix belongs to that workload rather than to the sensor.
Fix 2: Check RFM and Sensor Health First
A sensor that has fallen into Reduced Functionality Mode, or is failing repeatedly, is a different problem wearing the same symptom. Rule it out before tuning anything:
sudo /opt/CrowdStrike/falconctl -g --rfm-state
sudo /opt/CrowdStrike/falconctl -g --rfm-reason
Confirm the sensor's own view of its configuration:
sudo /opt/CrowdStrike/falconctl -g GET_OPTIONS
And check the kernel is supported by the installed sensor:
uname -r
sudo /opt/CrowdStrike/falcon-kernel-check
If the host is in RFM, resolve that first — see fixing "Host is in RFM". A sensor in RFM is not protecting the endpoint, which is a more urgent finding than the CPU usage that led you here.
Review recent sensor log entries for repeated errors:
sudo grep falcon /var/log/messages | tail -n 100
On Windows, confirm the service state:
sc query csagent
Fix 3: Update the Sensor
Performance fixes ship in sensor releases. Before investing in tuning, confirm the host is not several versions behind:
sudo /opt/CrowdStrike/falconctl -g --version
Compare against the versions available in your sensor update policies and move the host forward through your normal staged process. This is the lowest-risk fix available and resolves a meaningful share of cases.
Fix 4: Apply Scoped Exclusions for Known-Good Workloads
When a specific, trusted, high-churn workload is responsible, exclusions are the supported answer. This is exactly why CrowdStrike publishes exclusion guidance for SQL Server, Hyper-V hosts, IIS and similar roles.
Apply them properly:
- Scope narrowly. Exclude a specific data directory, not a whole volume. Exclude a named binary, not a directory of binaries.
- Prefer vendor-documented exclusions for the application in question over ones you invent from observed load.
- Document every exclusion with the reason and the requester. Exclusions accumulate silently and outlive the problems that justified them.
- Review them periodically and remove ones no longer needed.
Every exclusion is a region where the sensor is not looking. That is an acceptable, deliberate trade for a known-good workload on a known-good path, and a poor trade if used as general performance tuning. See configuring exclusions in CrowdStrike Falcon for how to define them correctly.
Fix 5: Review the Linux Backend Mode
The Linux sensor supports three backend settings — auto, bpf (user mode only) and kernel (kernel mode only) — configured through falconctl. auto is the default and lets the sensor pick the appropriate mode for the running kernel.
Pinning a backend is a targeted intervention for a diagnosed problem, not a speculative performance tweak. The sensor must be stopped before the change and restarted afterwards, which means a brief protection gap, and choosing the wrong mode for your kernel can put the host into RFM.
Do this with CrowdStrike support rather than on your own judgement. They can tell you whether your specific kernel and workload combination is a known case, which is the difference between a fix and a self-inflicted outage.
Verify the Fix
After any change, confirm both that CPU has settled and that protection is intact — the second is the part that gets forgotten.
# CPU over a real interval, not a single sample
top -b -n 5 -d 10 | grep falcon-sensor
# Sensor still running
ps -e | grep -e falcon-sensor
lsmod | grep falcon
# Not in RFM
sudo /opt/CrowdStrike/falconctl -g --rfm-state
# Still talking to the cloud
sudo netstat -tapn | grep falcon
Then confirm in the Falcon console under Hosts → Host Management that the endpoint is connected with a recent check-in and is still generating telemetry.
Prevention
- Baseline before you need it. Record normal sensor CPU for each host role. Without a baseline, "high" is a guess.
- Keep sensors current through staged update policies, so performance fixes reach you without ad-hoc upgrades.
- Apply role-based exclusions at build time for database, hypervisor, backup and build servers, rather than reactively after a complaint.
- Right-size high-churn hosts. A CI runner producing millions of file events per hour will cost measurable CPU under any EDR product; that is a capacity planning input, not a defect.
- Audit exclusions quarterly. Remove those tied to decommissioned workloads — stale exclusions are pure risk with no remaining benefit.