github-actions-recovery-latency-audit_skill

Overview

This skill measures how quickly GitHub Actions workflows recover after failures and highlights workflow groups that remain failing too long. It ingests exported run JSON, constructs failure incidents by group, and produces ranked summaries and severity scores for triage or CI gates. The skill supports text or JSON output and can optionally fail CI when critical problems are detected.

How this skill works

The skill reads GitHub Actions run JSON files and groups runs by repository, workflow, branch, and event. It builds failure incidents (from first failing run until the next success), computes recovery latency for closed incidents, and reports unresolved incident counts and ages. Severity is assigned using configurable thresholds (p95 recovery hours and open-incident age/count) and output is emitted as a text summary or structured JSON suitable for automation.

When to use it

• Audit recovery performance across many workflows and branches.
• Detect workflow groups that are persistently failing or slow to recover.
• Gate CI or dashboards by failing the job when recovery risk is critical.
• Prioritize operational work by ranked recovery-risk groups.
• Run deterministic tests using a fixed NOW_ISO clock and fixture data.

Best practices

• Collect complete run JSON exports so group histories are accurate.
• Tune thresholds (WARN/CRITICAL hours and open-incident counts) to match your team’s SLA.
• Filter workflows, branches, events, or repos with the include/exclude regex options to focus analysis.
• Set MIN_RUNS to avoid noisy scoring of low-traffic workflows.
• Use OUTPUT_FORMAT=json for machine-readable alerts and text for human review.

Example use cases

• Regular nightly audit that ranks the top workflow groups by recovery p95 and unresolved incident age.
• CI pipeline that runs this skill with FAIL_ON_CRITICAL=1 to block releases when critical recovery risks exist.
• Operational runbook: identify long-lived unresolved incidents across branches and assign owners.
• Historical analysis using bundled fixtures to validate threshold choices and scoring behavior.
• Ad-hoc investigation when a release candidate shows unexpected failure patterns.