Scheduled Workflow Health Report
SkillProductivityLets your agent check the health of scheduled GitHub Actions workflows and report failing or flaky ones by owner.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Scheduled Workflow Health Report skill
About this capability
Generate a health report for scheduled GitHub Actions workflows in this monorepo. Use when asked about scheduled workflow health, nightly build failures, flaky CI, or workflow ownership.
What this skill tells your AI
The instructions your AI receives, as published by camunda/camunda in .claude/skills/ci-scheduled-workflow-health/SKILL.md and read by ahel’s review.
Generates an HTML report showing the health status of all scheduled GitHub Actions workflows in the camunda/camunda repository.
Then summarizes the concerning failing and flaky workflows by owner.
What it does
- Lists all workflow files from
git show main:.github/workflows/ - Filters to those containing a
schedule:trigger - Extracts the
# owner:comment from the first 20 lines of each YAML file - Queries the GitHub API (via
gh) for the last 5 scheduled runs onmain - Classifies each workflow:
- failing — most recent run failed AND all checked runs failed
- flaky — most recent run failed BUT some checked runs passed
- ok — most recent run passed
- no_runs / in_progress — no completed scheduled runs found
- Outputs
scheduled-workflow-report.htmlwith collapsible sections, owner info, and a legend
Prerequisites
gitwith access to themainbranch (fetched)ghCLI authenticated (gh auth status)python3
How to run
python3 .claude/skills/ci-scheduled-workflow-health/scripts/scheduled-workflow-report.py
The script is at: .claude/skills/ci-scheduled-workflow-health/scripts/scheduled-workflow-report.py.
Output: scheduled-workflow-report.html in the current directory. Open with a browser.
stderr shows progress and a summary of failing/flaky workflows with their owners.
Customization
RUNS_TO_CHECKconstant (default 5) controls how many recent runs to inspect per workflowOWNER/REPOconstants control the target repository- Owner extraction looks for
# owner: <team>in the first 20 lines of each workflow YAML
Key design decisions
- Uses
git show main:instead of filesystem reads to always reflect themainbranch state - Uses
gh api(no pagination) since we only need ≤5 runs per workflow - Filters API calls to
event=schedule&branch=mainto only see scheduled runs - HTML report uses
<details>for collapsible sections — failing/flaky are open by default
Signals
- GitHub stars
- 4k
- Forks
- 818
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
ci-scheduled-workflow-health- Source
- github.com/camunda/camunda