The Cobbler's Single Last: On the Folly of Standardizing the Sole
A cobbler’s last is the shaped form around which a shoe is built. It determines the fit, the posture, the very foundation of a step. In our pursuit of reliable services, we have become cobblers obsessed with a single, perfect last. We call it the standard health check. It’s a piece of received wisdom so fundamental it’s rarely questioned: every service must expose a uniform endpoint—/health, /status, /ready—that returns a 200 OK when things are nominally functional. We standardize its name, its response code, its JSON schema. We believe this uniformity grants us clarity, a common language for our load balancers and orchestrators to speak. But in doing so, I fear we are building systems that all walk with the same limp.
The flaw is not in the check itself, but in the dogma of its sameness. By demanding every service, from a monolithic API to a background video transcoder to a stateful real-time broker, conform to the same simplistic protocol, we incentivize the hollow signal. That /health endpoint becomes a ritual, not a revelation. It confirms the process is alive, but says nothing of its spirit. Can it connect to its primary database? Probably. But what about its connection pool exhaustion, or the creeping latency on its calls to that third-party geocoding service it depends on, or the fact that its internal queue is backing up because a downstream service is slowing? The standardized check, designed for the lowest common denominator, remains stubbornly, deceptively green.
We mistake uniformity for observability. A load balancer checking for a 200 is not observing a service; it’s checking a pulse. True health is contextual and multifaceted. The health of a cache is its hit-rate and memory pressure. The health of a queue is its depth and processing speed. The health of a computational service is its thread pool saturation and error rate per task. Forcing these diverse entities to report “healthy” through a binary, universal signal is like asking a poet, a carpenter, and a mathematician to all answer “yes” to the same question to prove they’re working. The answer tells you nothing of the quality or state of their work.
This leads to the second, more pernicious folly: the standardization of the health check encourages the standardization of failure. When all failures must be squeezed into the binary outcome of a single endpoint, we lose the texture of degradation. A service entering a degraded state—say, falling back to a slower algorithm—should perhaps return a 200 with a warning in its payload, or even a 206 Partial Content. But the rules of the standardized last forbid it. The orchestrator might kill the instance, making things worse. So instead, the service lies, claims it’s fully healthy until the moment it catastrophically isn’t, and the platform-wide monitoring, built on this brittle standard, misses the gradual decay entirely.
The better path is not to abandon health checks, but to abandon the single last. Let each service expose the checks that meaningfully represent its operational fitness. A primary /live endpoint for liveness is fine, but let it be the simplest gate. Then, encourage a /vitals endpoint that returns service-specific telemetry: queue depths, latency percentiles, error budgets. Let the load balancer or service mesh be taught to read these richer signals. Let our “standard” be a framework for meaning, not a mandate for conformity. A good cobbler knows that a boot, a ballet slipper, and a running shoe cannot be built on the same form. Our services, in their beautiful and necessary diversity, deserve the same consideration. Reliability is found not in sameness, but in the right fit.
Notes & further reading
A few pages I came back to while writing this: