One Failed Health Check Is Not a Reason to Kill It

One missed 1-second probe was enough for our automation to kill and relaunch a busy but healthy signed-in browser.

The pool that manages that browser tested for a wedge with a single 1-second probe of /json/version. One miss went straight to kill and relaunch.

How it turned up

We had an AI assistant work through a list of findings about our own automation. For this one it read the kill logic and saw that the wedge test was a single 1-second probe that led straight to a kill. It wrote 6 new tests first. They failed without the fix and passed with it.

What the pool checks before it kills

The pass now skips the kill if any one of these holds:

• A patient 8-second re-probe gets an answer.
• A live CDP lease holder exists.
• A CDP success was recorded within the last 15 minutes.

A browser that stays silent is still repaired once the 15 minutes pass.

A spin that wasn’t there

The same list had a finding about a window agent that was supposedly spinning. The assistant could not reproduce it. The window agent is parked on purpose and not running, and desk_live used 0.00 CPU-seconds over a 60-second sample. The loop had been rewritten to be event-driven on 9/25, inside the window the finding covers. It found no proven spin path, so there was no fix. If it recurs, the next step is a py-spy dump.

A hold that stays

Another finding was about the bridge holding messages while a session is busy. The assistant left it alone. The hold is deliberate, an existing test covers it, and the only real fix is risky. It triaged the finding with a proposal instead.

One more fix in the same commit

the CLI chrome launch now spots Chrome running on the agent profile with no debug port and fails fast with rc 3. The message names the cause, an app shortcut such as the WhatsApp PWA, and the safe command, the CLI chrome kill, which refuses while a session holds the lease. I added 4 tests. The shortcut still shares the profile, so a separate profile for WhatsApp is the real fix.

dxdev LESSON · paste into your AI coding agent
LESSON: Confirm A Single Failed Probe With A Patient Re-Check And Liveness Evidence Before Killing A Healthy Process
SOURCE: dxdev.com/blog/one-failed-health-check-is-not-a-death-sentence
WHAT HAPPENED: The pool's wedge test was a single 1-second probe of /json/version, and one miss went straight to kill and relaunch. An AI assistant reviewing a list of findings read the kill logic and spotted this. It wrote 6 tests first, which failed without the fix and passed with it. The pass now skips the kill if an 8-second re-probe gets an answer, if a live CDP lease holder exists, or if a CDP success was recorded in the last 15 minutes. A browser that stays silent is still repaired once the 15 minutes pass.
THE RULE: Never take a destructive recovery action on the strength of one short failed health check. Require a longer re-probe and independent evidence of recent use or ownership, while still repairing a process that stays silent past a bounded window.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Search your automation for any kill, restart, or relaunch path and confirm none fires on a single failed probe with a short timeout.
      2. Confirm the kill path re-probes with a longer timeout and also consults independent liveness signals, such as an active lease holder or a recent success timestamp, before acting.
      3. Confirm a truly unresponsive process is still repaired after a bounded window, and that tests cover both the skip-kill case and the eventual-kill case.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.