Failed on the agent's machine.

• mediumFailed push deliveries are permanently discarded when state is savedalert.mjs:215

  The alert worker catches each delivery error, then unconditionally adds the event to the log and saves the advanced decision state (lines 217-224). A temporary Telegram, Discord, or GitHub failure therefore consumes the transition without delivering it or retaining a pending delivery. Subsequent polls with the same sample produce no event, so recovery of the destination never delivers the missed alert.

  The workflow also exits successfully, concealing the failure from its status. This is an advisory reliability defect in the advertised push alerts, not content that blocks hosting. Persist per-destination pending deliveries and retry unsuccessful sends independently of state changes.

  Execute main() twice with mocked fetch and an in-memory filesystem (no real messages).

  Start state.json as {"awake":false,"idleStreak":0,"cpReady":false,"milestone":41} and events.json as [].

  Set TELEGRAM_BOT_TOKEN=fake-review-token, TELEGRAM_CHAT_ID=fake-chat, ISSUE_ALERTS=0, with no Discord webhook.

  On both runs return {"measurement":{"freshness":"online","coreStatus":"ACTIVE","rpmMilli":22400},"builder":{"status":"available","anchor":{"blockHeight":4195}}} from the status endpoint and an eth_call result encoding (false,1975,false).

  Make Telegram sendMessage return HTTP 503 on the first run and HTTP 200 if called on the second.

  Expected: the failed wake alert remains pending and is sent after recovery.

  Actual, reproduced: run 1 logs "telegram failed: HTTP 503 from api.telegram.org", saves awake=true and the wake event, and exits successfully; run 2 logs "events: none" and makes no Telegram request, permanently losing that push notification.

  whole reproduction

• mediumCounter faults generate false bedtime and wake-up alertsalert.mjs:97

  The status reader maps every fresh coreStatus other than ACTIVE to running=false. The official API also permits COUNTER_FAULT (https://docs.squeekchain.com/developers/api/#pipeline-status-get-v1status), which reports a device fault, not confirmed inactivity. Three fresh fault readings therefore trigger "The hamster fell asleep"; recovery to ACTIVE then triggers a false wake-up even if the wheel never stopped.

  This contradicts the stated handling of unknown data and sends misleading alerts. Only IDLE should count as an idle observation; faults and unknown statuses should remain unknown. This is an advisory alert-correctness issue, not a hosting blocker.

  Start decide state as {"awake":true,"idleStreak":0,"cpReady":false,"milestone":41}.

  For three consecutive calls to readSample(), mock GET /v1/status as {"measurement":{"freshness":"online","coreStatus":"COUNTER_FAULT","rpmMilli":0},"builder":{"status":"unavailable","reason":"counter_fault"}}, and return eth_call data encoding (false,1975,false).

  Pass each sample into decide and carry its state forward.

  Expected: the readings remain unknown and no sleep event is emitted.

  Actual, reproduced: readSample returns running=false each time; idleStreak advances to 1, then 2, and the third call emits kind=sleep and sets awake=false.

  A fourth sample with coreStatus=ACTIVE then emits kind=wake without any observed IDLE reading.

  whole reproduction

• lowPolling across several block milestones drops all but the last alertalert.mjs:73

  The milestone branch advances the stored milestone directly to the newest hundred and emits only one event. When the settled height crosses multiple hundreds between polls (for example after delayed polling or batched settlement), intermediate milestones are lost permanently. The hosted page promises an alert each time the height passes a multiple of 100 (index.html:113).

  Emit an event for each crossed boundary, or explicitly document and display an aggregate notification covering the skipped range. This is a low-severity completeness issue and does not prevent hosting.

  From the repository root run: node --input-type=module -e 'import {decide} from "./alert.mjs"; const sample=h=>({running:null,rpm:0,checkpoint:null,blockHeight:h}); const first=decide({},sample(4199)); const next=decide(first.state,sample(4401)); console.log(next.events.map(e=>e.title)); console.log(decide(next.state,sample(4401)).events);'.

  Expected from the advertised every-100-block behavior: alerts for 4200, 4300, and 4400.

  Actual, reproduced: only ["Squeek block 4400 reached"] is emitted, the stored milestone becomes 44, and the following poll returns []; the 4200 and 4300 events never appear in push notifications or the feed.

  whole reproduction