From 8e2c3ed8ffe7ee6f5d7f464e46680b670d99268e Mon Sep 17 00:00:00 2001 From: Gavin Lucas Date: Fri, 9 Oct 2026 14:58:16 +0100 Subject: [PATCH 1/2] State that a failed post reaches nobody, as an accepted limitation The README said a broken webhook shows as a red watcher run "rather than a failure that reached nobody". The watcher's run is itself unwatched and nothing reports it, so a webhook that stops working is in practice noticed only when posts stop arriving. That is now stated plainly as accepted, with the alternatives considered and what ruled them out: an issue filed in the failing repository scatters them across every repository, and one filed here needs either a credential that can write across repositories or a scheduled sweep of every repository's watcher runs. Signed-off-by: Gavin Lucas --- README.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index f7a27d3..39091ba 100644 --- a/README.md +++ b/README.md @@ -146,9 +146,12 @@ jobs: secret set on the organisation is every repository's default, and a repository secret of the same name overrides it. An incoming webhook posts to one channel and can do nothing else. - **A post that fails, fails the watcher's run**, with Slack's answer in the error: a missing - secret, a webhook Slack refuses, or Slack unreachable after retries. So a broken webhook shows - as a red watcher run rather than a failure that reached nobody. A transient refusal is - retried, which can post the same failure twice. + secret, a webhook Slack refuses, or Slack unreachable after retries. A transient refusal is + retried, which can post the same failure twice. **Accepted limitation:** 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. Filing an issue instead was considered: in the failing + repository it scatters them, and in this one it needs either a credential that can write + across repositories or a scheduled sweep of every repository's watcher runs. - **The watcher only fires from the default branch**, where GitHub reads `workflow_run` triggers. So a change to it is tested only once merged. - **The caller must grant** `actions: read` and `contents: read`, as the example does, or From 9d3af3b62321e9e545b047f7d43f980683fe28bb Mon Sep 17 00:00:00 2001 From: Gavin Lucas Date: Fri, 9 Oct 2026 15:01:15 +0100 Subject: [PATCH 2/2] Correct the reporter's own header, and give the limitation's reasons rather than its history The workflow's header still said a broken webhook is a red watcher run rather than a failure that reached nobody, the claim the README no longer makes. It now states the limitation and points to the README. The README's alternatives are given as reasons instead of as a record that they were considered. Signed-off-by: Gavin Lucas --- .github/workflows/slack-on-failure.yaml | 5 +++-- README.md | 6 +++--- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/.github/workflows/slack-on-failure.yaml b/.github/workflows/slack-on-failure.yaml index e1d486e..f0b5179 100644 --- a/.github/workflows/slack-on-failure.yaml +++ b/.github/workflows/slack-on-failure.yaml @@ -12,8 +12,9 @@ name: 'Report a failed run to Slack' # nobody anticipated is posted rather than passed over. The filters are here, not in each # caller, so no caller can get them wrong. # -# 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. +# 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). on: workflow_call: inputs: diff --git a/README.md b/README.md index 39091ba..4462642 100644 --- a/README.md +++ b/README.md @@ -149,9 +149,9 @@ jobs: secret, a webhook Slack refuses, or Slack unreachable after retries. A transient refusal is retried, which can post the same failure twice. **Accepted limitation:** 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. Filing an issue instead was considered: in the failing - repository it scatters them, and in this one it needs either a credential that can write - across repositories or a scheduled sweep of every repository's watcher runs. + noticed only by the absence of posts. 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. - **The watcher only fires from the default branch**, where GitHub reads `workflow_run` triggers. So a change to it is tested only once merged. - **The caller must grant** `actions: read` and `contents: read`, as the example does, or