The Potter’s Unglazed Clay: On the Vessel That Holds Its Shape by What It Lacks

In a potter’s workshop, the most critical moment of truth doesn't come after the final firing, when the glazed jug emerges from the kiln, brilliant and impermeable. It comes much earlier, after the vessel has been thrown on the wheel but before it has seen even a drop of glaze. This is the stage of the ‘greenware’—a piece of pottery that is bone-dry, fragile, and unadorned. Its integrity is not yet sealed; it is held together solely by the structural soundness of its form and the evenness of its drying. A potter will run a hand over this unglazed piece, not checking for beauty, but for the faintest hairline crack, the subtle warping, the weakness invisible to anyone who only admires the final product.

This act of inspecting the unglazed clay is a profound parallel to a practice we often neglect in building services: the health check of an internal, non-public-facing component. We are excellent at monitoring our ‘glazed’ surfaces—the public APIs, the customer-facing endpoints. We set up elaborate uptime monitors that ping these endpoints, and we celebrate the green checkmarks on our dashboards. But what of the internal data aggregator that feeds the API? What of the caching layer that sits behind it, or the background process that refreshes its data? These are our service’s greenware. They are unglazed, hidden from the outside world, but the entire structure of the service depends on their soundness.

A service can appear perfectly healthy to an external monitor while it is slowly crumbling from within. The public endpoint might return a 200 OK status code, but the data it serves is stale, cached for hours because the internal worker tasked with updating it has silently failed. The latency might be low, but only because the service is returning error messages from a fallback that should never have been triggered. We are admiring the shine of the glaze while the clay beneath is cracking.

The potter teaches us that true resilience is built and verified in the raw state. In our architectures, this means implementing rigorous internal health checks that are separate from external uptime monitoring. It means creating probes that authenticate into the internal state of the system and ask questions of its organs, not just its skin. Is the message queue being consumed? Is the internal database connection pool healthy? Is the configuration file for the service valid and loaded correctly?

These checks measure the system’s integrity by assessing what it lacks: the absence of blocked threads, the lack of memory leaks, the non-existence of stale locks. Like the potter feeling for the absence of cracks, we are testing for the absence of failure conditions. This requires a shift in perspective from observing what the system does for a user to understanding what it is in its raw, unadorned state. The unglazed vessel holds its shape not by its shiny exterior, but by the intrinsic quality of its form. In the same way, a reliable service is not defined by its successful responses alone, but by the silent, internal soundness that makes those responses possible in the first place.

Notes & further reading

A few pages I came back to while writing this: