The Navigator's Cross Bearings: On the Single Check That Tells Two Truths

In the old craft of coastal navigation, a mariner with a sextant could fix their position not by a single landmark, but by taking bearings on two. Where the lines intersected on the chart, there was the ship. This principle of triangulation, of deriving a more profound truth from intersecting perspectives, is one we can apply directly to the reliability of our services. We often talk about adding more checks, more metrics, more dashboards. But complexity is its own kind of fog. Simplicity, when applied with precision, can be far more illuminating.

Today, let’s talk about a simple, concrete technique: using a single, well-placed health check to tell you two critical things at once. It’s a method that moves beyond the binary "up or down" and into the more practical reality of "up, but how?" Most health check endpoints are designed to be as lean as possible, perhaps returning a "200 OK" and a simple JSON payload from a location close to the application. This is fine for confirming the process is running, but it tells you nothing about the user's actual path to that process.

The technique is this: configure your uptime monitor’s health check to hit an endpoint that performs a lightweight, non-disruptive query against your primary database. The trick, however, is to have your monitor probe this endpoint from outside your infrastructure, from a location representative of your users. Now, this single request is no longer just checking if the application is alive. It has become a continuous, end-to-end validation of the entire data path. The response time of this check becomes a direct measurement of the latency between your user and the very heart of your service's data layer.

When you do this, the "up" signal splits into a richer story. A successful response still confirms the application server and the database are communicating. But a latency spike, while the service remains technically "up," is a clear and immediate warning. It tells you that something is amiss in the connective tissue of your system—perhaps a network issue between your hosting provider and the wider internet, an unexpected load on the database causing slow queries, or a regional routing problem affecting a segment of your users. It’s the difference between knowing the lighthouse lamp is lit and knowing that the lamp is lit and the fog horn is audible from the shipping lane.

This compound check forces a shift in your response. Instead of a simple "all systems operational" or "service is down" alert, you might get an alert stating "Service is experiencing elevated database latency." This specificity is a gift to the person on call. It directs their investigation instantly, bypassing a dozen preliminary steps. They know to look at database performance, network graphs, or DNS resolution, rather than wondering if the web server has simply crashed. It is a single point of observation that confirms two separate, vital truths: the integrity of the internal service connection and the health of the external pathway to the user. It is the navigator’s cross bearing, drawing two lines on your operational chart to show you exactly where you stand.

Notes & further reading

A few pages I came back to while writing this: