A signed document came back invalid, and the logs said nothing about why.
Multi-party signing flow on a high-ticket asset deal: each signature attaches to the deal record and has to stand up later. On my machine it signed and verified clean, run after run. In production it failed occasionally, and not twice in the same place.
The signature carried a validity window. The host that minted the timestamp and the host that verified it were not the same host, and their clocks were not the same clock. Some signatures came out a moment in the future relative to the verifier, so the verifier refused them, correctly: not yet valid.
My laptop had one clock, so that whole class of bug was invisible there. Containers don't help you either, because a container still reads the host clock.
The cost wasn't compute. It was documents parked mid-workflow, and counterparties asked to sign again for no reason they could see. In a deal flow that reads as a credibility problem, not a bug report.
What I do differently now: time in a signing or expiry path is data with a source, not something a process invents. One authority issues it, usually the database, and each window carries an explicit tolerance, written down instead of inherited from whatever drift happens to be true that day.
The rule I took from it is broader than clocks. Anything my machine has exactly one of (one clock, one process, one worker, one region) is a guarantee I'm depending on without having chosen it.
I write these up in longer form here: https://polycratia.com/c/e931c899
Curious which single-instance assumption bit you hardest: clock, process, worker count...