State that a failed Slack post reaches nobody, as an accepted limitation

[GavinLucas]

What

The README's Slack reporter section said a broken webhook shows as a red watcher run "rather than a failure that reached nobody". The watcher's run is itself a run nobody is watching, and nothing reports it, so a webhook that stops working is noticed only by the absence of posts. This states that as an accepted limitation, with the alternatives considered.

Alternatives considered

• An issue filed in the failing repository: it reaches GitHub's notifications, but scatters failures across every repository.
• An issue filed in this repository by the reporter: a workflow's token can write only to its own repository, so this needs a GitHub App or a personal access token that can write here. That is a new credential to own and rotate.
• A scheduled sweep here of every repository's watcher runs: keyless, since every repository is public, but another scheduled job, up to an hour late, and blind to a private repository.

Testing

Documentation only.

[github-actions]

Claude review: changes requested

Findings

1. maintainability — the workflow header still makes the claim this PR withdraws
.github/workflows/slack-on-failure.yaml:15-16:

# A post Slack does not accept fails this job, so a broken webhook is a red run of the watcher
# rather than a failure that silently reached nobody.

The PR removes the README's "rather than a failure that reached nobody" because the watcher's run is itself unwatched. This comment says the same thing in almost the same words, and nothing in the PR touches it. After merging, the README says a webhook that stops working is noticed only when posts stop arriving, while the reporter's own header still says a broken webhook is caught. Someone reading the workflow, which is where they would look when changing the failure handling, gets the claim the PR set out to correct.

Since correcting that claim is the whole point of the PR, this should be fixed here. Something like: "A post Slack does not accept fails this job, with Slack's answer in the error. Nothing reports the watcher's own run, so a webhook that stops working is noticed only by the absence of posts: an accepted limitation (README.md)." That fits the existing pattern, where the cancelled-run limitation appears both in the README and in the step comment at slack-on-failure.yaml:83-88.

2. maintainability (minor) — "was considered" is a record of the decision, not a reason
README.md:151-154: "Filing an issue instead was considered: in the failing repository it scatters them, and in this one it needs…". The reasons are worth keeping because they say why the limitation stands. But "was considered" records what was done when the decision was made, and the commit message (8e2c3ed) already records that, with the same reasons. Stating the reasons directly keeps the useful part without the history, for example: "Filing an issue instead would scatter them across repositories if filed in the failing one, and if filed here would need either a credential that can write across repositories or a scheduled sweep of every repository's watcher runs." This is minor and doesn't block merging by itself.

Checked

• There is no CLAUDE.md or AGENTS.md in the repository, so I reviewed against the README and the code it describes.
• "nothing reports it": this is true of the code. report-failures.yaml lists only 'Check inbound changes'. The hygiene check in actions/repo-hygiene/check-repo-hygiene.py, function unattended_run_findings, skips watcher files when it looks for unattended workflows (if relative in watchers: continue), so it neither requires nor expects anything to watch the watcher.
• "A transient refusal is retried, which can post the same failure twice": this is unchanged and still matches curl --retry 3 in the post step.
• Other copies of the old claim: I searched for the old wording ("reached nobody", "red run", "red watcher"). The only remaining copy is the one in finding 1.
• Recorded state: I checked the added README lines for it. Apart from finding 2, they state an accepted limitation and the reasons for it, which is allowed.

Not checked

• I did not check whether GitHub would actually allow a watcher to list its own name in workflow_run (chaining depth and recursion rules). The README doesn't claim either way, so this doesn't affect the review.

---

full review of c406e0fddc7d..8e2c3ed8ffe7. Run.

[GavinLucas]

Both taken in 9d3af3b: the reporter's header now states the limitation and points to the README, and the README gives the alternatives' reasons directly rather than recording that they were considered.

[github-actions]

Claude review: approve

Resolved

• Workflow header repeated the withdrawn claim (.github/workflows/slack-on-failure.yaml:15-17). The header now says the job fails with Slack's answer in the error, that nothing reports the watcher's own run, and that a dead webhook is noticed only by the absence of posts. It points to the README as an accepted limitation. This matches the README and the existing step comment about the cancelled-run limitation.
• "Was considered" in the README (README.md:152-154). The sentence now gives the reasons directly: filing in the failing repository would scatter issues across repositories, and filing here would need either a cross-repository credential or a scheduled sweep. It no longer records the history.

Still open

None.

Declined

None.

New

None. The delta is two comment and documentation edits. I read the full diff and searched the repository for "reached nobody" and "red run". Nothing else carries the old claim. The new text states a limitation and the reasons for it, not recorded state, and the code still supports it. I did not run the workflows. The change is text only, and the YAML comment lines are valid.

---

delta review of 8e2c3ed8ffe7..9d3af3b62321. Run.

[GavinLucas]

Not merging this and updating pins all round just for a few comments.