[operations] MTTR Badge (mttr-badge.yml) hourly scheduled job has no failure alert — public badge can silently go stale

[hivecommons-hive]

Summary

.github/workflows/mttr-badge.yml ("MTTR Badge") runs hourly (cron: '17 * * * *')
and computes/publishes the project's Mean-Time-To-Resolution metric to a public
Shields.io endpoint badge gist, displayed at the top of README.md. It has no
failure-alerting mechanism:

• No issues.create / issue-creation step inside the workflow itself.
• Not listed in .github/workflows/workflow-failure-issue.yml's workflow_run
  catch-all (workflows: list covers Release, Build and Deploy KC, Nightly
  Compliance & Perf, Nightly Dashboard Health, Nightly gh-aw Version Check,
  Playwright Cross-Browser (Nightly), Card Loading Standard, Startup Smoke Tests,
  Auto-QA Agent/Tuner, Nil Safety, GA4 Error Monitor, OpenSSF Scorecard, Weekly
  Coverage Review).
• Not part of the 13 jobs already tracked in [operations] In-Place Upgrade Smoke canary (self-upgrade path) and 12 other scheduled workflows have no failure alert #23144/[operations] docs: add runbook for 12 remaining scheduled CI jobs with no failure alert #23230 (upgrade-smoke.yml and
  its 12 documented siblings) — mttr-badge.yml does not appear in either list.

A scheduled failure — e.g. a GitHub search-API rate limit/error, or an expired/
revoked GIST_TOKEN — currently produces only a red ❌ in the Actions tab. Worse,
some non-failure conditions (gist PATCH returning non-OK, GIST_TOKEN unset, or no
Fixes/Closes refs found in the last 100 merged PRs) exit the job successfully
(status 0) while only console.log-ing a skip message — so the badge can silently
freeze at a stale value even when every scheduled run shows green.

Because this badge is public (README.md line 7) and tied to the recovery-time SLI
referenced by SLO 5 in docs/SLO.md / docs/INCIDENT-RESPONSE.md's 4-hour target,
a silent staleness here misrepresents the project's actual incident-response
performance to the community with no internal signal that it happened.

Confirmation

Reviewed .github/workflows/mttr-badge.yml and .github/workflows/workflow-failure-issue.yml
directly in a fresh clone of kubestellar/console. Verified via
gh run list --repo kubestellar/console --workflow=mttr-badge.yml --limit 10 that
the last 10 scheduled runs (2026-09-07) all show conclusion: success — consistent
with the gap never having been exercised recently, not with it being otherwise
covered. Cross-checked "MTTR Badge" against every workflow name in the catch-all's
workflows: list and against the two other operations tracking issues covering
scheduled-workflow alert gaps (#23144, #23230); none reference mttr-badge.yml.

Suggested fix

Add "MTTR Badge" (exact name: value) to the workflows: list in
workflow-failure-issue.yml — same mechanism already used for the 14 other
monitored jobs, requiring no new code path. Separately, consider making the
silent-skip cases (missing GIST_TOKEN, non-OK gist PATCH) call
core.setFailed(...) so they surface through the same catch-all once wired up,
rather than exiting 0.

Why no CI config file change in the linked PR

The operations agent's GitHub App token lacks the workflows permission required
to create or update files under .github/workflows/ (confirmed in multiple prior
sessions — see docs/runbooks/upgrade-smoke-no-alert.md,
docs/runbooks/stale-workflow-no-alert.md). A docs-only runbook
(docs/runbooks/mttr-badge-no-alert.md) documents the interim manual-detection
workaround and this proposed fix for a maintainer with that permission to apply.

— hive: agent=operations backend=copilot model=claude-sonnet-4-6

[hivecommons-hive]

Re-verification (this session, 2026-09-10/11)

Confirmed still open. Same gap class as #23144 — attempted the PR path via hive-open-pr again this session and hit the same platform-level block: the operations App token lacks the workflows permission scope needed to push a commit under .github/workflows/.

A single consolidated, tested diff covering this issue and the other four in this gap class (#23144, #23119, #23193, #23235, #23268) is now attached to #23144 for a maintainer with workflows App permission to apply directly — closing all five at once.

— hive: agent=operations backend=copilot model=claude-sonnet-4-6