Description
The Agent Job Health Monitor's 2026-10-07 schedule-heartbeat check (#66705) found 4 workflows that declare a schedule: trigger but are disabled_manually in GitHub Actions, each showing a large "gap" that looks like a cron misfire but is actually an intentional disable with no corresponding decision recorded in the repo:
| Workflow |
Last run |
Gap |
daily-geo-optimizer.lock.yml |
2026-08-18 |
50.3 days |
daily-hippo-learn.lock.yml |
2026-07-27 |
72.7 days |
slide-deck-maintainer.lock.yml |
2026-09-23 |
14.3 days |
smoke-ci.lock.yml |
2026-07-18 |
81.6 days |
Because the source .md still declares a schedule: (confirmed live: daily-hippo-learn.md:8 has cron: "daily around 7:00", slide-deck-maintainer.md:7 has cron: "daily around 16:00 on weekdays"), every fleet-health report has to re-flag these four as apparent blind spots, when the real issue is just that nobody has made (or recorded) a keep/retire decision since they were disabled.
Expected Impact
Removes 4 recurring false-positive entries from every future schedule-heartbeat / fleet-health check, and gets 4 workflows off limbo (either genuinely back in service or cleanly retired).
Suggested Fix
For each of the 4 workflows, either:
- Re-enable it (
gh workflow enable <name>.lock.yml) if it's still wanted, or
- Remove the
schedule: trigger (keep workflow_dispatch only) or delete the workflow source/lock pair if it's intentionally retired.
Suggested Agent
Repo maintainer decision needed per-workflow (not a pure code fix) — a coding agent can execute whichever decision is made.
Estimated Effort
Fast (< 30 min) — a disable/retire decision per workflow, no code logic involved.
Data Source
DeepReport Intelligence Briefing — incremental cycle since #66663 (cycle 12), sourced from Agent Job Health Monitor report #66705 (Schedule Heartbeat section) and live verification of each workflow's frontmatter.
Generated by 🔬 Deep Report · claude · agent · 171.9 AIC · ⌖ 5.12 AIC · ⊞ 7.1K · ◷
Description
The Agent Job Health Monitor's 2026-10-07 schedule-heartbeat check (#66705) found 4 workflows that declare a
schedule:trigger but aredisabled_manuallyin GitHub Actions, each showing a large "gap" that looks like a cron misfire but is actually an intentional disable with no corresponding decision recorded in the repo:daily-geo-optimizer.lock.ymldaily-hippo-learn.lock.ymlslide-deck-maintainer.lock.ymlsmoke-ci.lock.ymlBecause the source
.mdstill declares aschedule:(confirmed live:daily-hippo-learn.md:8hascron: "daily around 7:00",slide-deck-maintainer.md:7hascron: "daily around 16:00 on weekdays"), every fleet-health report has to re-flag these four as apparent blind spots, when the real issue is just that nobody has made (or recorded) a keep/retire decision since they were disabled.Expected Impact
Removes 4 recurring false-positive entries from every future schedule-heartbeat / fleet-health check, and gets 4 workflows off limbo (either genuinely back in service or cleanly retired).
Suggested Fix
For each of the 4 workflows, either:
gh workflow enable <name>.lock.yml) if it's still wanted, orschedule:trigger (keepworkflow_dispatchonly) or delete the workflow source/lock pair if it's intentionally retired.Suggested Agent
Repo maintainer decision needed per-workflow (not a pure code fix) — a coding agent can execute whichever decision is made.
Estimated Effort
Fast (< 30 min) — a disable/retire decision per workflow, no code logic involved.
Data Source
DeepReport Intelligence Briefing — incremental cycle since #66663 (cycle 12), sourced from Agent Job Health Monitor report #66705 (Schedule Heartbeat section) and live verification of each workflow's frontmatter.