You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
loop-lane: decide an external dead-man's switch for scheduled lanes #7673
The claude.dev post "Building effective agent automations" (2026-10-08, https://claude.dev/blog/building-effective-agent-automations/) shows a watched heartbeat: a scheduled run signals success to something outside itself, so a run that never starts is noticed. Today the morning-brief skill marks a lane STALE once its last cycle is older than --stale-hours, but that is a pull view nobody sees until someone runs the brief. Digest entry 6.
Question
Q8: file a decision, not a monitor choice. Find out:
Should scheduled lanes send an end-of-run success signal to an external absence-of-signal monitor, alerting when the signal misses its period plus a grace window?
Which monitor, if any, and who watches the monitor's own alert path?
Does a push alert beat the morning-brief pull view for this repo's lanes?
How do GitHub schedule delays, dropped runs and the 60-day schedule disable on public repos affect the period and grace values?
Acceptance criteria
A recorded decision (ADR or convention section) states adopt or reject, with its basis.
If adopted: the chosen monitor, the signal each lane sends and when, the period and grace per lane class, and how the alert path is itself watched.
If rejected: what replaces it, or why the pull view suffices.
The decision names how a lane that never starts is detected.
Related
docs/conventions/liveness-assertion: asserts liveness inside the repo; this issue decides whether an external watcher is added on top.
Verified: request valid. No ADR or convention on main (e59e0be) records an external absence-of-signal monitor for scheduled lanes; docs/conventions/liveness-assertion asserts liveness in-repo only, and the morning-brief STALE view is pull-only, as the body says.
Why a human: the item asks for an adopt-or-reject decision on shared infrastructure that may add an external service and an alert path someone must watch. That is cross-repo, shared-infrastructure policy, which triage does not default.
What an agent can do first, if the owner wants it before deciding: a read-only research pass that answers the four questions in the body (monitor options, who watches the alert path, push vs the pull view, and how GitHub schedule delays, dropped runs and the 60-day public-repo schedule disable bear on period and grace) and drafts the ADR with both outcomes for the owner to pick. Say so on this issue and it can be flipped to agent-ready + work-class: read-only for that pass.
No RECOMMENDED answer is given: the deciding evidence (which monitor, its cost and trust model, and how often lanes have silently not started) has not been gathered.
Brief for the decision
Type: Task Summary: Decide whether scheduled lanes send an end-of-run success signal to an external absence-of-signal monitor.
Acceptance criteria:
A recorded decision (ADR or convention section) states adopt or reject, with its basis.
If adopted: the monitor, the signal each lane sends and when, period and grace per lane class, and how the alert path is itself watched.
If rejected: what replaces it, or why the pull view suffices.
The decision names how a lane that never starts is detected.
Decision recorded. Question: adopt an external dead-man's switch for the scheduled lanes? Owner's answer: yes, the recommended option. Use the healthchecks.io free tier (20 checks, https://healthchecks.io/pricing/). Each scheduled lane's last step pings https://hc-ping.com/<ping-key>/<slug> on success. One repository secret holds the ping key. Each check's schedule matches its workflow's cron, with a grace window longer than the worst measured delay (pr-merge's 15-minute schedule has gone 60.6 minutes between runs). A run skipped by the lanes kill switch must not trigger an alert. The morning-brief pull view stays as the backstop. Basis: GitHub sends nothing for a scheduled run that never starts, and may drop queued scheduled jobs (https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).
Decision recorded. This supersedes the earlier decision on this issue. Question: pause the healthchecks.io heartbeat build? A ping-on-success heartbeat catches a scheduled lane that stops running, which has not happened here, and it would not have caught the 2026-10-17 intake failure (green runs that skipped the work, now reported by ci-workflows#773's skip notice). Owner's answer: pause, revisit on evidence. Closing as not planned; reopen if a scheduled lane is ever found to have silently stopped.
Activity
github-actions commentedon Oct 16, 2026
Thanks for the report. Automated triage handed this issue to a maintainer.
Automated triage. A maintainer reviews it.
kyle-sexton commentedon Oct 18, 2026
This was generated by AI during triage.
Triage: human-gated (Task, priority: medium)
Verified: request valid. No ADR or convention on main (e59e0be) records an external absence-of-signal monitor for scheduled lanes;
docs/conventions/liveness-assertionasserts liveness in-repo only, and the morning-briefSTALEview is pull-only, as the body says.Why a human: the item asks for an adopt-or-reject decision on shared infrastructure that may add an external service and an alert path someone must watch. That is cross-repo, shared-infrastructure policy, which triage does not default.
What an agent can do first, if the owner wants it before deciding: a read-only research pass that answers the four questions in the body (monitor options, who watches the alert path, push vs the pull view, and how GitHub schedule delays, dropped runs and the 60-day public-repo schedule disable bear on period and grace) and drafts the ADR with both outcomes for the owner to pick. Say so on this issue and it can be flipped to
agent-ready+work-class: read-onlyfor that pass.No RECOMMENDED answer is given: the deciding evidence (which monitor, its cost and trust model, and how often lanes have silently not started) has not been gathered.
Brief for the decision
Type: Task
Summary: Decide whether scheduled lanes send an end-of-run success signal to an external absence-of-signal monitor.
Acceptance criteria:
Out of scope:
kyle-sexton commentedon Oct 18, 2026
Decision recorded. Question: adopt an external dead-man's switch for the scheduled lanes? Owner's answer: yes, the recommended option. Use the healthchecks.io free tier (20 checks, https://healthchecks.io/pricing/). Each scheduled lane's last step pings
https://hc-ping.com/<ping-key>/<slug>on success. One repository secret holds the ping key. Each check's schedule matches its workflow's cron, with a grace window longer than the worst measured delay (pr-merge's 15-minute schedule has gone 60.6 minutes between runs). A run skipped by thelaneskill switch must not trigger an alert. The morning-brief pull view stays as the backstop. Basis: GitHub sends nothing for a scheduled run that never starts, and may drop queued scheduled jobs (https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).kyle-sexton commentedon Oct 18, 2026
Decision recorded. This supersedes the earlier decision on this issue. Question: pause the healthchecks.io heartbeat build? A ping-on-success heartbeat catches a scheduled lane that stops running, which has not happened here, and it would not have caught the 2026-10-17 intake failure (green runs that skipped the work, now reported by ci-workflows#773's skip notice). Owner's answer: pause, revisit on evidence. Closing as not planned; reopen if a scheduled lane is ever found to have silently stopped.