How to fix Felix is not live: liveness probe reporting 503 in Kubernetes

KubernetesADVANCEDHIGHUpdated Dec 6, 2025· 144 views

Felix is Calico's policy engine. "Felix not ready" errors indicate liveness probe failures due to timeouts or dataplane issues. Fix by reviewing logs, adjusting probe timings, and ensuring dataplane health.

Quick fix

Fixes Felix is not live: liveness probe reporting 503

kubectl logs -n calico-system ds/calico-node -c calico-node --tail=100
  1. Check Calico node pod logs
  2. Check Felix liveness and readiness probe configuration
  3. Adjust liveness probe timeout
  4. Check node system resources
kubernetes — error
kubectl logs -n calico-system ds/calico-node -c calico-node --tail=100
Felix is not live: liveness probe reporting 503

What this error means

Felix is Calico's main policy enforcement engine running on every node. When Felix reports not ready or not live, it means the liveness/readiness watchdog timers have not received check-ins from critical internal loops. This prevents the Calico node from becoming ready, blocking pod scheduling.

Typical symptoms

  • Calico node pod shows CrashLoopBackOff or not ready state
  • Pod logs show "Felix is not live" or "Felix is not ready"
  • Liveness/readiness probes failing with HTTP 503
  • Warnings like "report timed out" for Felix components
  • Network policies not being enforced
  • Calico nodes repeatedly restarting
  • Health endpoint reporting non-ready status
  • Felix CPU or memory usage very high

Common causes

  1. Internal Felix loop (dataplane, policy, discovery) not responding within timeout
  2. High system load causing Felix loop latency
  3. Dataplane integration issues with kernel or eBPF
  4. Memory pressure or resource exhaustion
  5. Kernel incompatibility with Felix requirements
  6. Liveness probe timeout set too low
  7. High number of policies or endpoints causing slow processing
  8. Bugs in Felix version deployed

How to fix "Felix is not live: liveness probe reporting 503"

1Check Calico node pod logs

Review detailed Felix error messages:

bash
kubectl logs -n calico-system ds/calico-node -c calico-node --tail=100

Look for "report timed out" messages indicating which component is slow.

2Check Felix liveness and readiness probe configuration

Review probe settings in the daemonset:

bash
kubectl get daemonset -n calico-system calico-node -o yaml | grep -A 10 "livenessProbe|readinessProbe"

Default timeouts may be too aggressive for slow systems.

3Adjust liveness probe timeout

If system is slow, increase the probe timeout:

bash
kubectl patch daemonset calico-node -n calico-system --type json \
  -p '[{"op": "replace", "path": "/spec/template/spec/containers/0/livenessProbe/timeoutSeconds", "value": 10}]'
4Check node system resources

Verify CPU and memory are not exhausted:

bash
kubectl top nodes
kubectl top pod -n calico-system ds/calico-node

If resources are high, add more CPU/memory to the node.

5Increase Felix log level for debugging

Get more detailed logs by adjusting Felix configuration:

bash
kubectl edit configmap -n calico-system felix-config

Set logSeverityScreen to Debug:

yaml
logSeverityScreen: Debug
6Check Felix component health individually

Use calicoctl to check component health:

bash
kubectl exec -it -n calico-system ds/calico-node -- \
  wget -q -O- http://localhost:9099/liveness

Returns 200 if live, 503 if not.

7Verify kernel version and compatibility

Ensure kernel supports Felix requirements:

bash
uname -r
grep -i ebpf /proc/version

Minimum kernel version depends on Calico version. Check compatibility matrix.

8Restart Calico node daemonset

If logs show intermittent issues, try restarting:

bash
kubectl rollout restart daemonset/calico-node -n calico-system
kubectl rollout status daemonset/calico-node -n calico-system

Advanced notes

For production clusters, monitor Felix health proactively using Prometheus metrics. Very large clusters (100+ nodes) with thousands of policies may have slow Felix loops - consider splitting policies or using policy templates. If Felix keeps timing out despite adjustments, upgrade Calico to latest version as performance improvements may address the issue. Track kernel compatibility as eBPF features and requirements evolve with Calico versions.

Frequently asked questions

What does "Felix is not live: liveness probe reporting 503" mean?
Felix is Calico's main policy enforcement engine running on every node. When Felix reports not ready or not live, it means the liveness/readiness watchdog timers have not received check-ins from critical internal loops. This prevents the Calico node from becoming ready, blocking pod scheduling.
How do I fix "Felix is not live: liveness probe reporting 503"?
Felix is Calico's policy engine. "Felix not ready" errors indicate liveness probe failures due to timeouts or dataplane issues. Fix by reviewing logs, adjusting probe timings, and ensuring dataplane health.
What causes "Felix is not live: liveness probe reporting 503"?
Internal Felix loop (dataplane, policy, discovery) not responding within timeout High system load causing Felix loop latency Dataplane integration issues with kernel or eBPF
Is the "Felix is not live: liveness probe reporting 503" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading