The Cobbler's Last: On the Shape of a Monitored Thing
A cobbler’s workshop is a world away from a server rack. It smells of leather and wax, not of chilled air and humming fans. Yet, in the corner of that workshop sits a tool that holds a profound lesson for anyone trying to build a reliable service: the last. This heavy, foot-shaped form is what a shoemaker builds a shoe around. It gives the shoe its fundamental structure, its purpose, its very identity. Without it, you’re just stitching leather; with it, you’re crafting something that fits, functions, and endures.
In our world of uptime checks and latency graphs, we often forget to define our ‘last’. We deploy probes and health checks because we know we should. We measure response times for our homepage, our API endpoints, our database connections. The green checkmarks pile up, creating a comforting, if illusory, sense of security. But are we measuring the right shape? Is our service a simple shoe, or is it a complex boot with laces, a tongue, and a reinforced heel? Are our probes just checking if the sole is attached, while the customer is struggling with a broken lace?
False Confidence in a Misaligned Mold
The peril of a poorly chosen last is a shoe that looks fine on the shelf but pinches with every step. Similarly, a poorly conceived health check creates a dangerous false positive. Consider an e-commerce service. A simple HTTP 200 status check on the product page might be our ‘last’. It’s a basic shape. But a customer’s journey is more complex. They add an item to a cart, which touches the cart service. They attempt checkout, which requires inventory and payment services. If our monitoring is built only around the product page ‘last’, a failure in the payment service will go unnoticed until the support tickets flood in. The shoe has fallen apart, but our simple mold told us everything was fine.
A cobbler chooses a last specifically for the foot it will adorn and the activity it will support. A work boot’s last is different from a ballet slipper’s. Our monitoring must be just as intentional. We need to build our checks around the true ‘shape’ of a user’s interaction with our service—the critical user journey. This synthetic transaction, a script that mimics a real user from login to completion of a key task, is our complex, multi-part last. It ensures that all the interdependent components are not just individually alive, but working in concert to provide a functioning whole.
Furthermore, a good cobbler knows a last isn’t forever. Feet change, styles evolve. Our services are even more dynamic. We ship new features, refactor old code, and integrate new systems. The ‘shape’ of our service changes. A monitoring strategy built on a static, simplistic last will quickly become obsolete. We must periodically re-evaluate our health checks. Are they still tracing the true outline of what makes our service valuable? Or are we just comfortably polishing a shoe that no one can wear? The goal is not just to confirm that our service is up, but to verify that its unique, intricate form is still sound, from sole to lace.
Notes & further reading
A few pages I came back to while writing this: