elastic / elastic/ai-github-actions
[product-manager-impersonator] Scheduled Workflow Health Watchdog
- Dominant language
- Python
- Stars
- 11
- Forks
- 16
- Avg merge
- 22h 9m
- Merged PRs (30d)
- 31
Description
## Feature Idea
**Summary:** Add a reusable workflow that detects consecutive scheduled-workflow failures (and stale-success windows) and files one deduplicated health issue with direct run links.
## Why a Customer Would Want This
Teams adopting these workflows need fast signal when automation silently degrades. Today, failures appear as separate `[aw] ... failed` issues, which is noisy and hard to triage as a pattern. A single health watchdog issue makes it obvious which workflows are repeatedly failing and where to act first.
## Rough Implementation Sketch
- Add a new reusable workflow source (for example, `.github/workflows/gh-aw-scheduled-workflow-health.md`) modeled on `Scheduled Audit` with `actions: read` permissions and safe-output issue reporting.
- In the workflow prompt/setup step, query recent workflow runs, group by workflow path/name, and flag rules like “N consecutive failures” or “no successful run in X days.”
- Emit one consolidated issue using `close-older-key` semantics so only the latest health report stays open.
- Add `gh-agent-workflows/scheduled-workflow-health/{README.md,example.yml}` and catalog docs entry.
## Why It Won't Be That Hard
This repository already has the key building blocks:
- Reusable scheduled-audit scaffolding and deduplicated issue reporting (`.github/workflows/gh-aw-scheduled-audit.md` lines 3-5, 45-49, 67-83).
- Existing run-metadata collection via `gh api repos/$GITHUB_REPOSITORY/actions/runs` (`.github/workflows/agent-efficiency.md` lines 69-73).
- Existing scheduled trigger pattern and detector/fixer chaining expectations (`.github/workflows/trigger-bug-hunter.yml` lines 5-7, 21-27; `docs/upgrading.md` lines 11-13, 28-33).
## Evidence
- Current base workflow model supports this pattern directly: `gh-aw-scheduled-audit.md` already defines a generic scheduled detector with safe outputs and duplicate controls.
- There is repeated failure noise in recent open issues: `#688` (`[aw] PR Labeler failed`), `#696` (`[aw] Issue Triage failed`), `#691` (`[aw] Project Summary failed`), `#693` (`[aw] Internal: Downstream Health failed`), `#695` (`[aw] Duplicate Issue Detector failed`).
- Existing related issues are adjacent but not duplicates:
- `#448` tracks no-op transparency (successful no-action runs), not recurring failure aggregation.
- `#245` tracks downstream update compatibility, not local scheduled run reliability.
- Open product-manager issues focus on quick-setup and output ergonomics, not scheduled failure trend detection.
---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Trigger Product Manager Impersonator](https://github.com/elastic/ai-github-actions/actions/runs/23138865819)
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
Contributor guide
Assessment
This issue has not been assessed yet.