The BGP Leak: An Outage You Cannot See
In one line: this is the concrete case that justifies the whole chapter. It is a total outage for affected users, produced entirely outside your infrastructure, and invisible to every metric you collect.
What happened
Read the two ends of that diagram together. On the left, users are completely unable to reach the service. On the right, every dashboard is green — correctly, because nothing the provider owns is broken.
Why BGP makes this possible
BGP is how networks tell each other which addresses they can reach, and it operates largely on trust. A network announcing "send me traffic for these addresses" is generally believed by its peers.
So a misconfiguration at someone else's organization can redirect your traffic, globally, in minutes — with no bug in your code, no failure in your infrastructure, and no way for you to fix it directly.
The DNS chapter noted that anycast relies on BGP to route users to the nearest instance. This is the same mechanism's failure mode: the routing layer that normally works in your favour can be pointed the wrong way by a third party.
Not an isolated incident
BGP route leaks are not isolated incidents. On April 16, 2021, an autonomous system mistakenly announced more than 30,000 BGP prefixes, resulting in a 13x increase in inbound traffic. Network operators detected the surge and mitigated the misconfiguration.
| Detail | Value |
|---|---|
| Date | April 16, 2021 |
| Scale of the mistake | More than 30,000 BGP prefixes announced in error |
| Effect | 13x increase in inbound traffic to the affected network |
| How it ended | Network operators detected the surge and mitigated it |
Why traditional monitoring misses it
Traditional infrastructure monitoring may not capture these external routing events, so engineers must implement dedicated external connectivity monitoring.
The reason is structural, and worth stating plainly:
| Monitoring type | Vantage point | Sees a BGP leak? |
|---|---|---|
| Server metrics | Inside your infrastructure | ✗ — everything is genuinely healthy |
| Application logs | Inside your infrastructure | ✗ — the requests never arrive to be logged |
| Load balancer health checks | Inside your infrastructure | ✗ — backends respond normally |
| Traffic volume | Inside your infrastructure | weak — a dip, but inside normal variance if regional |
| External connectivity monitoring | Outside, from the client's position |
Every row that fails shares one property: the vantage point is inside. You cannot detect a failure in the path to your building by looking around inside the building.
Key takeaway
A BGP leak is a total outage for affected users, caused by a third party, with every one of your own signals reporting health. It is the clearest possible argument that some monitoring must live outside the system it watches.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "Network problems could stop users reaching us." |
| L5 | Names the mechanism: "a BGP misconfiguration by a peer can redirect our traffic, and we'd have no internal signal because our servers are fine." |
| Staff+ | Generalizes it: "every internal signal is blind here by construction — you can't see a failure in front of your infrastructure from inside it. Same principle as failure independence for replicas: to detect a failure in a layer, you have to observe from outside that layer." |
Next: the obvious solution, and where it runs out.