GitHub uses eBPF to detect circular dependencies in deployment

GitHub Engineering published a detailed engineering post on April 16, 2026, about how it uses eBPF (extended Berkeley Packet Filter) technology to improve the safety of its deployment processes. The post shows a concrete production use case for eBPF beyond its standard network observability domain.

The problem: invisible circular dependencies

Large distributed systems like GitHub’s have thousands of internal services with a complex dependency network. Circular dependencies — where service A needs service B to start, and B directly or transitively needs A — are not just an academic problem. They become critical during cold-start deployment of an entire environment or during a disaster recovery scenario.

The worst circular dependencies are invisible in architectural diagrams because they arise through deep transitive connections that nobody explicitly documented. A deploy script calls another script that invokes a tool that connects to an API that depends on a service that depends on the first one.

The post identifies three types of circular dependencies that GitHub monitors as potential system hazards.

Why eBPF?

eBPF allows the execution of safe, sandbox-isolated programs directly in the Linux kernel, which can intercept system calls, network events, and other kernel activities without modifying applications. This is a key advantage because deployment scripts come from many teams and different languages.

Instead of requiring every script to instrument itself, GitHub wrote an eBPF program that:

1. Selectively monitors network access from the deployment context
2. Analyzes which services are called from which scripts
3. Automatically builds a graph of real runtime dependencies
4. Detects cycles and alerts engineers before they turn into a production incident

Kernel-level observability for DevOps

Technically, this approach demonstrates the maturation of eBPF beyond its original networking role. Over the past few years, eBPF has expanded into:

• Security: Falco, Tetragon for runtime threat detection
• Observability: Pixie, Parca for profiling without instrumentation
• Networking: Cilium for service mesh and CNI

GitHub’s post adds yet another category — deployment safety as part of the platform engineering stack. Instead of looking for dependencies through static analysis of configuration files, it observes the actual runtime behavior of the system during deployment.

For engineers working on large platforms and SRE teams, the post offers a practical study of how eBPF has grown from a networking tool into a general observability layer for the operating system.