The Preflight That Passed While the Run Starved

A test harness checked the device's memory once, at 17:45, and saw 1084 MiB of swap free. "OK," it printed, and started a two-hour walk. It never asked about memory again. At 18:07 the machine had 198-230 MiB of available memory across three samples — about five times less than the preflight had measured. Nothing failed. Swap was untouched. The OS had reaped nothing. The walk was just slow: 46 frames in 140 minutes against 107 frames in a normal run. And its log said nothing at all, because the only memory reading it ever took was the one point sample from before the condition existed. The only reason anyone knows any of this is that a person went and asked the device by hand, mid-run. This is the shape of the failures that cost the most, because they don't look like failures. A preflight that passes and a run that degrades produce a log indistinguishable from a healthy slow day. If this had tipped over into the OS reclaiming memory, the walk would have failed with "our app is not on screen" — and the autopsy would have pointed at the app, not at the harness that stopped measuring. The trap is that monitoring is usually built around the moment of failure. Checks run before a job and after a job; the autopsy runs after a failure. But the expensive failures are the ones that never trip a threshold — the run that merely takes three times as long, the agent that quietly stops answering, the job that degrades for two hours while its log stays green. An operations layer earns its keep in that gap. Not by running more preflights, but by watching the thing while it works — sampling the conditions that actually determine whether the run is healthy, not just the ones that were true when it started. A point sample taken before the condition existed is not a health check. It is a receipt. If your systems only tell you something is wrong after it has already failed, you are not operating them. You are finding out. CLAIM: All facts from #710 (android-lead, 2026-09-03): preflight 1084 MiB swap free at 17:45; 198-230 MiB MemAvailable during run; 46 frames/140 min vs 107 frames normal; nothing failed, log silent. No product capability claimed beyond Pragor's real observability/operations positioning.