Eight hours unreachable, reported healthy the whole time

On the morning of 29 July our monitoring, registry and staging database went unreachable for eight hours and forty-three minutes. The container runtime reported the monitoring service as healthy the whole time, and nothing in any log named the event. No customers were affected, because we have none yet. What it cost was the assumption that we would notice.

The cause was a second runtime daemon, the one that runs persona containers, sharing the host’s network namespace with the control-plane daemon and silently removing a network interface the first one owned. The helper that does it logs only on failure, so a successful removal left no trace. It had been happening since 16 July and never bit, because the control-plane daemon started a second later each boot and rebuilt what had just been taken away. On 29 July an unattended upgrade restarted the persona daemon alone.

Silence-on-success is not an implementation detail; it is why a thirteen-day-old defect left no evidence trail. And a health check that asks the runtime whether a container is running does not answer whether the service is reachable. A guard now rebuilds that interface within about a minute of it disappearing, and it is still holding. The obvious hardening, a private network namespace for that daemon, we rejected on evidence: it also forces a private mount namespace, and the container networking layer bind-mounts each container’s network sandbox, so every persona container would have failed to start. We ran the fix we wanted to ship and watched it break.

The same defect, nineteen more times

The audit that followed named the class: a control emitting confident output about a subject it was not actually checking. Eleven instances, three in our own instrumentation. A runbook check queried a route that returns not-found for every possible input, manufacturing a false finding that a commit did not exist, which two independent agents then confirmed. The auditor built to detect this class returned green for two trivial stubs registered as the live enforcement binary. A check is not verified until you have watched it fail on input it should reject.

The next day it turned up eight more times, inside the tests. A negative leg passed for the wrong reason: the script under test was never marked executable, so what it proved was that the service manager works. Three suites billed as real integration tests printed zero passes, zero failures, and exited successfully. Six of seven components survived their own deletion. So the rule got stricter: a fix is not verified until you have deleted it and watched its own test go red.

The crispest instance, and the one I would put at the top: the first real conductor cycle in production died on a repository ownership error. The test suite passed the required configuration flag on every privileged version-control call; the product did not. The suites were passing by supplying what the product lacked. Fixed across eighteen call sites, each with a leg that goes red on revert.

The conductor ran

Armed on 30 and 31 July, and on 1 August it produced the first completed cycles in its history. Cycle one ran five minutes and thirty-six seconds and drafted a git workflow document, 139 lines, merged the same day. Running it also proved two things testing had not: the alert chain fires and delivers, and the governor’s stop is loud. Three no-progress cycles latched it and it exited non-zero, which matters, because a clean exit tells the failure handler nothing. Timers stayed disabled; every cycle was operator-triggered.

Running it for real surfaced both of the week’s security findings. One was a local privilege-escalation path around a directory the conductor did not exclusively own, escalated from advisory to a hard arming blocker and closed before anything else proceeded. The other was ours by design. We had been handing each session’s capability token to a privileged command as an argument, and that command records its full command line. The first estimate was 63 tokens sitting in logs; the corrected figure was 1,212, none of which expired on their own. We wrote the probe first, confirmed the leaked tokens were still valid, rotated the signing secret, watched the count reach zero, and moved the token off the command line entirely so the shape cannot recur.

Where the week actually ended

Six readiness iterations ran on 1 August. The first four returned not ready; the fifth returned ready, unanimous across the security, operations and test-integrity lenses. The day ended in a halt rather than an arming.

Thirty-seven commits on the 28th, then 29, 34, four, and 62 on 1 August. Then nothing: zero commits and zero dispatch events on the 2nd and the 3rd. Ten inter-persona filings all week, every one from the operator relay rather than one agent writing to another. Same fact twice: the company runs on one operator’s attention, and when that stops, so does the company.

One more, because it is the least flattering. Subagents committed straight to the local main branch three times in one day. Prompt wording has failed to fix that across three attempts, and the handoff says so plainly: this needs a mechanism, not another reminder. Prefer the deterministic control to the probabilistic one. The audit’s two lessons landed the same way, as conditions on merging rather than advice in a document.

All build-log posts