Troubleshooting¶

Quick fixes for the issues teams hit most often.

No alerts appearing¶

You triggered something (like a shell in a container) but nothing shows on the dashboard.

Check Falco is running on every node:
```
kubectl get pods -n kubesentry -l app.kubernetes.io/name=falco
```
There should be one Running Falco pod per node.
Check Falcosidekick can reach the collector. If events aren't arriving, this link is the usual culprit. Look at the Falcosidekick logs:
```
kubectl logs -n kubesentry deploy/kubesentry-falcosidekick
```

Check the collector is receiving:

kubectl logs -n kubesentry deploy/kubesentry-collector

Confirm your action landed in a watched container — try exec-ing into a different, definitely-running pod.

Falcosidekick can't reach the collector¶

If Falco fires but the collector never logs the event, the Falcosidekick → collector wiring is likely off. This is almost always a release-name / Service-name mismatch: Falcosidekick's output URL points at the fixed Service name kubesentry-collector, which only exists when you install with the release name kubesentry (or set fullnameOverride=kubesentry). If you installed under a different release name, reinstall as kubesentry:

helm uninstall <your-release> -n kubesentry
helm install kubesentry kubesentry/kubesentry -n kubesentry --create-namespace

Falco pods crashing or CrashLoopBackOff¶

Usually a driver/kernel issue.

Confirm your nodes' kernels support the modern_ebpf driver (modern kernels do).
Check the Falco pod logs for the specific driver error:
```
kubectl logs -n kubesentry <falco-pod>
```
On unusual or older kernels you may need to adjust the Falco driver settings via the falco.driver values. See the Falco driver docs.

`exec format error` when pods pull the image¶

The node's architecture doesn't match the image. The published collector image is multi-arch (amd64 + arm64), so a clean pull should just work. If you see this, confirm you're pulling ghcr.io/kubesentry/collector (the public multi-arch image) and not a stale single-arch build.

Confirm the upgrade actually applied the license value:
```
helm get values kubesentry -n kubesentry
```
Make sure the token was copied whole — no line breaks or trailing spaces.
Reload the dashboard (hard refresh). The collector re-reads the license on the rolled pod.
Check the collector logs for a license validation message; a malformed or expired token logs a validation failure and falls back to trial.

Dashboard is empty but pods are healthy¶

Verify you're port-forwarding the right Service and port (svc/kubesentry-collector on 8080) and opening /dashboard.
Give it a moment after install — the feed only populates once an event fires. Trigger a test detection (see Quickstart).

Alert history disappeared after reinstall¶

History lives on a PersistentVolume. If it's gone, the PVC was likely deleted. Confirm collector.persistence.enabled: true and that your StorageClass retains volumes. See Storage.

Still stuck?¶

Grab the collector logs and your (secret-free) values.yaml, and reach out via support on the KubeSentry site.