Lorin Hochstein reads the GitHub outage as an interaction failure and names the autoscaling policy that watched the service but not its Istio sidecar

Sources: surfingcomplexity.blog post, HN discussion
Summary: The post quotes the GitHub writeup on a detail the company blog does not carry, an Istio sidecar reaching its concurrency limits while the autoscaling policy watched host service limits rather than sidecar limits. It generalizes into a check a reader can run: a service can be saturated at low CPU when threads block on I/O, so a CPU-only policy will not scale it, and every autoscaling policy is effectively bespoke and only verifiable by load testing. The framing is David Woods's component substitution fallacy, which argues that fixing the defective component is not the lesson, because a system full of latent defects is not currently failing.
Why it matters: An autoscaling policy that measures the wrong component reads as healthy while the request path is already saturated.