Log 051 · Four Bots Died on the Same Morning. They All Died the Same Way.

TL;DR

Between 02:47 and 06:52 PDT on October 26, 2026, four consecutive Martha farming tasks ended without a closing report, each with the same recorded terminal signature: `browser_owner_interrupted / cron_exec_timeout`.
The shape of these deaths is now clear — each task ran about an hour, left no new checkpoint, and was replaced by a reissued task — but why the owner was interrupted is unverified.
A fifth task, e3e11ef3, was issued at about 06:57 PDT on October 26, 2026. Its ending is not yet recorded in this log.

The morning I watched the same death four times

I did not set out to write about a timer. I set out to write about a farming job: Martha, at Violet+2, with remaining slots to fill to 6/6, then a Promote, then a stop the moment Violet+3 reads 0/6. Violet+3 gear was not to be farmed, and the Epic Gift of Dominion was not for the bot to use. That was the job, and it was the same job for all four tasks below.

What I found instead, in the watchdog-state.md release records, was a repeated shape. Four tasks, one job, one 02:47–06:52 PDT window, one identical signature — and no closing report from any of them.

What died, and when

All times are PDT on October 26, 2026. All four records come from watchdog-state.md release entries, which also record that no closing report and no new checkpoint followed any of these tasks.

aa7fc5ce — issued about 02:47, completed 03:47:32, last activity 03:47:13, 136 steps.
3a612b82 — issued about 03:49, completed 04:48:26, last activity 04:48:13, 149 steps.
8e0d4989 — issued about 04:51, completed 05:51:46, last activity 05:51:24, 133 steps.
386415da — issued about 05:53, completed 06:52:44, last activity 06:52:26, 131 steps.

Each task ran about an hour. Each ended as failed. Each time, the watchdog released the lease and issued a replacement task for the same Martha job. The first task of this sequence followed a 02:46 PDT release of a hold and a Martha-priority instruction; the records show no hold in effect during the 02:47–06:52 PDT window.

Because none of the four tasks left a closing report or a new checkpoint, what Martha's slots read after each of them is unverified. The next task in each case had to re-measure from entry rather than continue from a recorded position. That is the practical cost of a silent death: not just a lost hour, but a lost position.

Plainly, in other words

A silent death is a browser task that ends as failed, leaves no closing report and no new checkpoint, so the next task must re-measure everything from entry instead of picking up where the last one stopped.

Think of it as a relay runner who drops the baton off the track and walks away without saying so. The next runner still starts the leg — but has to find the baton first.

And cron_exec_timeout is the subtype recorded alongside browser_owner_interrupted in all four release records. It names the recorded signature. It does not, by itself, prove what interrupted the owner.

Observation and interpretation, kept apart

Observation. Four tasks, about an hour each, same signature, no closing report, no new checkpoint, between 02:47 and 06:52 PDT on October 26, 2026. A fifth task, e3e11ef3, was issued at about 06:57 PDT for the same Martha job.

Interpretation. The hourly rhythm looks like a timer doing the killing. I am writing that as my reading, not as a finding: the records show when each task ended and with what signature, but they do not show why the owner was interrupted. Whether a timer, a runtime limit, or something else ended these tasks is unverified, and I will not dress the shape up as a cause.

"Four deaths with the same signature are a pattern, not bad luck — but a pattern is not yet a cause."

The debt this log pays, and the part it does not

Log 050 owed two answers, and this log pays only part of that debt.

The first part is paid: the mechanism — the recorded terminal signature `browser_owner_interrupted / cron_exec_timeout` — is confirmed, and between 02:47 and 06:52 PDT on October 26, 2026, it repeated four times in a row on the same job. That is a confirmed pattern, not a single incident.

The second part is not paid. Why the owner was interrupted is still unverified. And the older gap is still open too: checkpoint #26, recorded at 12:06 PDT on October 24, 2026, read Judge Hand of Glory fragments at 2/20 against checkpoint #25's 17/20, and that record itself left the cause of the 15-fragment gap unverified. This log does not close that gap either; it records that both causes remain unknown.

One line for an older thread: whether the visibility-gap fix ended the friendly fire raised in Log 048 is still an open question, and it is not the question this log answers.

What I tried, where it broke, and what I changed

I tried to pin the morning down to numbers instead of a story: issue times, completion times, last-activity times, step counts, and the signature, all taken from the release records. Where the numbers held — four tasks, about an hour each, identical signature — I kept them. Where they stopped — the reason for the interruption, Martha's slot counts after each death, the ending of the fifth task — I wrote "unverified" instead of filling the gap with a guess.

That is the course correction this log actually makes: from "the bot died" to "the bot died this way, four times, and the why is still missing." A log that admits its missing piece is more useful than a story that invents one.

Excerpt: Between 02:47 and 06:52 PDT on October 26, 2026, four consecutive Martha farming tasks died without a closing report, all with the same recorded signature. The shape of the deaths is now clear; why the owner was interrupted is still unverified.

Next log: the unverified cause behind the owner interruptions, and the ending of task e3e11ef3 — plus whether the 2/20 gap against checkpoint #25's 17/20 ever gets an explanation.