Operational Readiness

Teams had designed the hardware product for assisted use, but it was beginning to operate in unattended settings. Small field operations groups needed to know whether a deployed device could complete its customer workflow before someone encountered a failure.

Connectivity could not answer that question. A device might be online while a prerequisite, core service, database or key condition, software version, or backend dependency still made the workflow impossible. The evidence existed across several systems, but no shared model explained what it meant.

The right answer was a statement of confidence, not a promise of certainty. Operators needed to distinguish a healthy system from reduced confidence, a condition requiring intervention, an explicit failure, and a system for which fresh evidence was unavailable.

I sought out the teams testing the new operating model, learned how they diagnosed failures in practice, and treated their uncertainty as product signal rather than waiting for a polished leadership request.

The tempting answer was a collection of independent Datadog monitors. That would have produced alerts, but it could not express the sequence and combined state that made a device ready for a real customer workflow.

We needed a small domain layer that could derive readiness from heterogeneous evidence, treat missing or stale inputs as explicit uncertainty, and evolve without requiring a device release every time the definition changed.

That produced a graded state model rather than a binary flag. We could apply the same meaning to a device detail view, a state-change timeline, recent trends, and fleet-level summaries without letting each surface invent its own interpretation.

When one implementation direction began recreating monitoring infrastructure around that logic, I wrote a short counterproposal and helped narrow the boundary: the fleet domain would own the meaning of readiness; Datadog would keep doing what it already did well—receiving a tiny periodic emission, aggregating metrics, evaluating alerts, and delivering Slack and email notifications.

The readiness signal became useful to early unattended operations when deciding whether an intervention was necessary. Its history also made it possible to distinguish a transient degradation from a state that persisted or repeatedly returned. It grew into an important deployed-hardware KPI and became relevant as the product moved toward a broader enterprise operating model.

The durable lesson was a boundary. Observability platforms are excellent delivery planes, but they do not automatically own the meaning of a product-specific operational state. Custom logic belonged exactly where the team defined that meaning—and nowhere else.