The Bridgekeeper's Riddle: On the Three Questions That Aren't Enough

In the old tale, the keeper of the bridge asks three questions. Answer correctly and you may cross; fail and you are cast into the abyss. For years, our service health checks have felt like that: a few pointed questions—Is the port open? Does the endpoint return a 200? Is the response time under 500ms?—that we trust to grant safe passage to our users. We set our thresholds, and if the answers are green, we assume the bridge is sound. But what if the questions, while correct, are no longer sufficient to prove the bridge's true purpose?

We’ve all seen it. The dashboard glows with serene, verdant statuses. All three answers are perfect. Yet, somewhere, a user is staring at a mangled JSON response, a half-loaded page missing a critical asset from a third-party CDN, or a form that submits into a silent void because a downstream API accepted the request but entered a degraded state. The bridgekeeper’s questions verified the planks were present and could bear weight, but they did not ask if the planks were slick with ice, or if the handrail on the far side was missing.

The Transaction, Not the Echo

This is the subtle pivot from simple health checks to true journey observability. It’s the difference between asking a bridge if it’s a bridge, and asking if you can safely cross it with a full cart. The former is a check on its inherent properties; the latter is a synthetic transaction that mirrors a real user’s mission. A 200 OK from `/health` is an echo in the canyon. A successful, end-to-end process—logging in, adding an item to a cart, applying a discount code, checking out with a test payment method, and seeing the confirmation—is a full conversation.

That full conversation reveals what the simple riddle hides: the silent failure in the discount service that still returns a 200 but an empty array for valid codes. The creeping latency in the inventory lookup that hasn’t yet breached its 500ms threshold but adds a stutter to the flow. The third-party font provider that times out, leaving the page functional but visually broken. The bridge is technically open, but the journey is now fraught with minor perils and frustrations.

Crafting these journey checks requires a different mindset. You must think like a cartographer of purpose, not just a surveyor of structure. What is the user’s true goal? What sequence of actions, across which domains and dependencies, constitutes success? This check is inherently more fragile and more valuable—it’s a canary for experiential degradation long before the core infrastructure falters.

So, do not discard the bridgekeeper’s three questions. They are the foundation, the vital signs. But never let them give you a false sense of security. Build the checks that ask the fourth, fifth, and sixth questions: Can I complete the task? Is the experience whole? Does the outcome match the intent? Your service is not just a standing structure; it is a path to a destination. Monitor the traversal, not just the tollbooth.

Notes & further reading

A few pages I came back to while writing this: