---
title: "What Happens When the Cockpit Itself Goes Dark? Two Outages, Ten Stranded Jobs, One Spare Parked by Subtraction"
date: 2026-08-27
description: "E3: the chat channel died twice — 90-second stalls, then 10 jobs stranded at deliver; the fix was a 6-node pipe, and the spare parked for good."
category: "AI & Compute"
tags:
  - "One Man One Legion"
  - "AI Agents"
  - "Telegram"
  - "Feishu"
  - "Reliability"
  - "Personal Infrastructure"
verifiedHardware: "Workstation openclaw runtime · evidence = openclaw.json channels + cron jobs.json + run logs + 2 dated diagnosis docs (2026-06-20, 2026-07-04; 101 and 194 lines) · timestamps Asia/Shanghai · read 2026-08-27"
keyTakeaways:
  - "The June 20 outage was one dead domain: the proxy exit node every command traveled through returned NXDOMAIN from 4 independent DNS resolvers, and the gateway logged a polling stall every 90 seconds — the fix was not a better node but a pool of 6 (0.44–4.14 s), health-probed every minute behind a least-ping balancer (telegram-proxy-fix-2026-06-20.md)."
  - "On July 4 the pipe died upstream and 13 outbound jobs were stranded — 10 OpenClaw cron jobs and 3 system crontab scripts — with the work already done and products on disk; a four-row contrast experiment isolated the Feishu bug: agentTurn news jobs ran 149 and 112 seconds while the identical-envelope systemEvent job idled 10 seconds, its Telegram twin running 270 (feishu-migration-diagnosis-2026-07-04.md)."
  - "The repaired noon job fired on schedule after the fix — 11 run records through July 11 — and the Feishu news pair kept twice-daily schedules to the last fires on July 22 and 23, when the great contraction switched the auto-publishers off; today 0 of the 4 Feishu-routed entries are lit and 3 of the 4 lit jobs route to Telegram: the channel did not fail, the schedule was cut (run logs + jobs.json, 2026-08-27)."
measuredOn: 2026-08-27
faq:
  - q: "Why not just migrate everything to Feishu?"
    a: "The operator deliberately narrowed the July 4 mission to diagnose and stress-test — no migration. Feishu connects over a domestic websocket and needs no proxy, which made it the natural lifeboat, and the diagnosis found its envelope bug that same evening. The permanent fix turned out to be elsewhere: the proxy pipe got 6-node redundancy, and the cron contraction of late July removed most outbound pushes entirely. Feishu carried the repaired noon job to July 11 and the news pair to July 22–23, then went dark with the whole schedule — parked by subtraction, not by failure."
  - q: "What was the hardest part of the June diagnosis?"
    a: "The environment lied. An ambient proxy setting silently routed every overseas health-check through the very proxy that had died, so the first tests 'proved' the machine could not reach the internet at all. Unsetting the proxy revealed a perfectly healthy direct network. The general lesson: your diagnostic tool lives inside the system it is diagnosing and inherits its failures — bypass the ambient path before believing any connectivity verdict."
  - q: "What exactly was the envelope bug?"
    a: "A cron payload is an envelope: a kind, an instruction field, and a session target. The WeChat noon job used systemEvent + main + text, which Telegram's side processes normally — but the Feishu plugin does not process that kind: the event arrives, no agent turn starts, zero tokens are spent, the instruction text itself gets recorded as the summary, and the job is marked done after 10 seconds. The working Feishu envelope, proven by the news jobs the same evening, is agentTurn + isolated + message."
  - q: "Is the channel reliable now?"
    a: "No uptime is claimed — the evidence would laugh. What is on record: the June fix replaced a single exit node with a 6-node observatory-watched pool; July's outage was upstream of that pool; and at press time the newest cron run, an arXiv digest, finished with status ok on the Telegram side."
---
*[Episode 3 of One Man One Legion](/posts/2026-08-27-one-man-one-legion-fleet-audit/). [Episode 2](/posts/2026-08-27-one-man-legion-ep2-tg-gateway/) walked the tool bench behind the wheel — everything the copilot can do once a message arrives. This episode is about arrival itself: the channel, and the 2 days it died.*

Every chat-commanded legion has a single point of failure more basic than any model: the pipe the commands travel through. This is the story of that pipe's 2 deaths, what each one changed, and how the spare built to end the dependency was parked — not by failing, but by subtraction.

## June 20: the wheel goes silent

The first symptom was silence: messages to the bot got no answer, and the gateway log repeated itself every 90 seconds — polling stall, no updates fetched, restart, stall again. The bot was not broken; its lifeline was. Every fetch of new messages left the country through a proxy whose single exit node had ceased to exist — 4 independent DNS resolvers (Ali, Cloudflare, Google DoH, 8.8.8.8) all returned the same verdict, NXDOMAIN. One dead domain, and the whole cockpit went dark.

The diagnosis nearly went wrong. The machine carried an ambient proxy setting that silently routed every overseas health-check through the very proxy that was dead, so the first tests "proved" the box could not reach the internet at all. Bypassing it showed the truth: the direct network was fine. The operator wrote the rule down — unset the ambient proxy before diagnosing network problems — but it generalizes: your diagnostic tool lives inside the system it diagnoses, and inherits its failures.

The fix that shipped was not "a better node" but "no more single node": a pool of 6 nodes, measured latencies 0.44 to 4.14 seconds, a health probe every minute, a least-ping balancer, and a named fallback for the day every probe fails. The pipe became redundant. The channel stayed Telegram.

## July 4: stranded at deliver

14 days later the pipe died again — upstream this time — and the failure had a cruel shape: the legion kept working. 13 outbound jobs failed that day, 10 OpenClaw cron jobs and 3 system crontab scripts, and in every case the collecting, the writing, the synthesis had already succeeded. The products sat on disk while the last step — sending them to the group — timed out. Work done, delivery dead.

Feishu was the designated lifeboat: a domestic websocket channel that needs no proxy, already warm — enabled, plugin installed, 3 news jobs running on it. The operator narrowed the day's mission on purpose: do not migrate; diagnose and stress-test the one Feishu job that looked broken.

## The four-row experiment

What settled it was a contrast table — same evening, same channel:

| Job | Envelope | Result |
|---|---|---|
| Feishu news, morning | agentTurn + isolated | ran 149 seconds, tokens spent, real summary |
| Feishu news, evening | agentTurn + isolated | ran 112 seconds, same shape |
| Feishu WeChat, noon | systemEvent + main | 10 seconds, empty session, zero tokens, summary = the instruction itself |
| Telegram WeChat, noon | systemEvent + main, character-identical payload | 270 seconds of real work |

The identical envelope works on Telegram and idles on Feishu. That is a plugin behavior mismatch, not a configuration error: the Feishu side receives the event, starts no agent turn, and marks it done. And the bug had 2 more defects stacked beneath it: the job's clock said 8:05 while its name said noon (the Telegram twin runs at 12:00), and the WeChat channel had 5 slots on Telegram — 06:00, 07:30, 12:00, 17:20, 18:40 — against 1 on Feishu.

One honest footnote: the live stress test never ran. The gateway's external CLI refused connections twice — the rule is stop after 2 — while the internal scheduler proved itself another way: restarted at 22:15, it fired the Feishu news job on time at 22:20. The clock worked even when the door didn't.

## The spare, driven briefly

The repair was applied. The noon job's envelope was re-addressed to agentTurn + isolated and its clock aligned with its name; a one-shot diagnostic entry fired once on July 5 at 13:38. Then the spare drove: the repaired noon job logged 11 run records through July 11; the news pair kept twice-daily schedules to the last fires on July 22 and 23 — 19 records each — until the great contraction ([Episode 19](/posts/2026-08-27-one-man-legion-ep19-cron-contraction/)) switched the auto-publishers off. The channel did not fail; the schedule was cut.

The cockpit read from live configuration 35 days later: 2 enabled channels — Telegram with 12 groups, Feishu on websocket — but 0 of the 4 Feishu-routed cron entries are lit, and 3 of the 4 lit jobs route to Telegram. (The fourth's name still points at a group while its key says main. Names drift; keys don't lie.) The migration meant to save the cockpit never happened, and didn't need to: the pipe got redundant, the schedule got cut, and the spare stayed mounted — warm, verified, and parked.

## What we claim and what we don't

The 2 outage narratives come from 2 dated diagnosis documents (June 20, 101 lines; July 4, 194 lines), cross-checked against live state read on August 27: channel enablement and the 12-group count from the runtime config, routing and enable flags from the cron file, the Feishu jobs' run-record counts and ranges from their logs, and the newest run — an arXiv digest, status ok — as evidence the channel is alive at press time. Run records are counted, not audited for delivery success. The July 4 document's summary line says 13 OpenClaw jobs failed while its own table lists 10; we counted the rows. Latencies and the 270-second twin are the documents' measurements, not re-measured. No uptime is claimed for any channel or proxy.

Primary sources: `telegram-proxy-fix-2026-06-20.md`, `feishu-migration-diagnosis-2026-07-04.md`, `openclaw.json` channels, cron `jobs.json`, run logs, 2026-06 to 2026-08.

*[All episodes](/posts/2026-08-27-one-man-one-legion-fleet-audit/) — One Man One Legion, an ongoing series.*