Problem
Four workflows show a 0-successful / 0-failed anomaly in metrics/latest.json (2026-08-22 collection), each with hundreds of "runs" but ~2 second average duration and a success_rate of 0.0:
| Workflow |
Total runs |
Successful |
Failed |
Avg duration |
squad |
423 |
0 |
0 |
2.1s |
squad-implement-worker |
106 |
0 |
0 |
2.2s |
deployment-incident-monitor |
93 |
0 |
0 |
2.2s |
workflow-generator |
8 |
0 |
0 |
2.4s |
None of these are genuine failures — a 2-second "run" with no successful/failed conclusion strongly suggests the runs are being recorded as skipped (e.g. slash-command/bot-gated triggers like squad's issue_comment/slash_command config that exit immediately when the trigger condition doesn't match) but the metrics collector's GitHub-API-fallback path (used because agentic-workflows logs timed out on every attempt this window, per latest.json's collection_note) isn't classifying skipped conclusions separately from success/failed, producing a 0.0 success rate that looks identical to total failure.
This degrades the reliability of automated health scoring (Workflow Health Manager, Agent Performance Analyzer) for these workflows and risks false P0/P1 escalation.
Evidence
/tmp/gh-aw/repo-memory/default/metrics/latest.json — collection_status: "complete", data_source: "github_api_fallback", note explicitly states the primary logs-based collection timed out on every attempt (count=80/20/5/3) and the API fallback pagination doesn't recover per-workflow success/failure/skipped breakdown for these four..github/workflows/squad.md — triggers on slash_command (issues, issue_comment, pull_request_review_comment) plus bots: ["github-actions[bot]"] gate; most comment events won't match, producing near-instant skips..github/workflows/deployment-incident-monitor.md, squad-implement-worker.md, workflow-generator.md — similarly event/dispatch-gated, consistent with high skip volume.
Suggested Fix
- In the Metrics Collector workflow, when using the GitHub API fallback path, explicitly classify
conclusion: "skipped" and conclusion: "action_required" runs separately from success/failure in the per-workflow rollup (instead of leaving successful/failed both at 0, which reads as 100% failure).
- Surface a
skipped count field per workflow in metrics/latest.json so downstream consumers (Workflow Health Manager, Agent Performance Analyzer) can exclude skip-dominated workflows from failure-rate scoring.
- Investigate why the primary
agentic-workflows logs collection path is timing out on every attempt (60s context deadline exceeded) — restoring it would give richer duration/cost data for all workflows, not just these four.
Priority
P2 — not a functional workflow failure, but a data-quality gap in the shared metrics pipeline that risks false alarms in downstream health/performance reports.
Generated by 🏥 Workflow Health Manager - Meta-Orchestrator · auto · 79.7 AIC · ⌖ 10.8 AIC · ⊞ 12K · ◷
Problem
Four workflows show a 0-successful / 0-failed anomaly in
metrics/latest.json(2026-08-22 collection), each with hundreds of "runs" but ~2 second average duration and asuccess_rateof0.0:squadsquad-implement-workerdeployment-incident-monitorworkflow-generatorNone of these are genuine failures — a 2-second "run" with no successful/failed conclusion strongly suggests the runs are being recorded as
skipped(e.g. slash-command/bot-gated triggers likesquad'sissue_comment/slash_commandconfig that exit immediately when the trigger condition doesn't match) but the metrics collector's GitHub-API-fallback path (used becauseagentic-workflows logstimed out on every attempt this window, perlatest.json'scollection_note) isn't classifyingskippedconclusions separately fromsuccess/failed, producing a0.0success rate that looks identical to total failure.This degrades the reliability of automated health scoring (Workflow Health Manager, Agent Performance Analyzer) for these workflows and risks false P0/P1 escalation.
Evidence
/tmp/gh-aw/repo-memory/default/metrics/latest.json—collection_status: "complete",data_source: "github_api_fallback", note explicitly states the primary logs-based collection timed out on every attempt (count=80/20/5/3) and the API fallback pagination doesn't recover per-workflow success/failure/skipped breakdown for these four..github/workflows/squad.md— triggers onslash_command(issues,issue_comment,pull_request_review_comment) plusbots: ["github-actions[bot]"]gate; most comment events won't match, producing near-instant skips..github/workflows/deployment-incident-monitor.md,squad-implement-worker.md,workflow-generator.md— similarly event/dispatch-gated, consistent with high skip volume.Suggested Fix
conclusion: "skipped"andconclusion: "action_required"runs separately fromsuccess/failurein the per-workflow rollup (instead of leavingsuccessful/failedboth at 0, which reads as 100% failure).skippedcount field per workflow inmetrics/latest.jsonso downstream consumers (Workflow Health Manager, Agent Performance Analyzer) can exclude skip-dominated workflows from failure-rate scoring.agentic-workflows logscollection path is timing out on every attempt (60s context deadline exceeded) — restoring it would give richer duration/cost data for all workflows, not just these four.Priority
P2 — not a functional workflow failure, but a data-quality gap in the shared metrics pipeline that risks false alarms in downstream health/performance reports.