Repository navigation
[agent-job-health] Agent Job Health Monitor - 2026-10-12 #68173
Closed
Replies: 1 comment
|
This discussion has been marked as outdated by Agent Job Health Monitor. A newer discussion is available at Discussion #68553. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Agent Job Health Monitor — 2026-10-12
Note
No fleet-wide regression. Failure rate is driven by a long tail of one-off, isolated failures rather than a broad or chronic pattern — but this run's log collection and issue-tracking checks were both partial; see caveats below before treating any number here as definitive.
Summary
/tmp/gh-aw/aw-mcp/logs/, only 231 had completeaw_info.json+run_summary.jsonpairs; the other 82 were incomplete (partial download) and excluded. This is not a full 24h sample — treat all rates below as a snapshot of a late-evening ~8.5h slice, not the full day.total_runs= 231,distinct_workflows= 61,agent_failures= 14/tmp/gh-aw/cache-memory/agent-job-health/history.jsonl): the most recent prior entry (2026-10-09) measured a run-weighted rate of 3.04% (with an upper bound of 18.25% due to 40 indeterminate runs that day) and a workflow-weighted mean of 13.62%. Today's 6.06% run-weighted rate is +3.0pp, and the mean (13.93%) is essentially flat (+0.3pp) — not a >10pp regression signal. Both the 2026-10-09 and today's entries share the same partial-window caveat (~7.8h and ~8.5h respectively), so day-over-day comparisons here are approximate.Tool Access Limitation (read this before the rest)
GitHub issue search and direct issue reads (
search_issues,list_issues,issue_read) were blocked by an integrity policy for the entire duration of this run (every call returned[Filtered] ... integrity policyor an empty result with a redaction notice). This means Phase 3 (Tracked vs. Novel classification) could not be performed live — I have no way to confirm which of today's failure clusters already have an open tracking issue.To avoid creating a duplicate issue, no new issue was opened this run. Instead, the clusters below are cross-referenced against the
tracked_issuevalues recorded in prior runs of this same history file (best-effort, may be stale — those issues could since have been closed, or new ones opened that I can't see).Failure Rate by Step
Tracked Failures (best-effort — see limitation above)
Novel Failure Clusters
Classification as "novel" vs. "tracked" is unverified this run (see limitation above). Reporting as clusters requiring human triage:
38309913711(Agentic Workflow Audit Agent, 2026-10-12T21:20:08Z). This exact step/engine combination does not appear in any prior entry of the trend history file, so it is plausibly genuinely new — but this could not be confirmed against open issues. Suspected root cause: codex engine's MCP gateway startup; blast radius appears codex-engine-specific rather than fleet-wide (only 2 of the ~organization's codex-engine runs failed this way in the window). Recommended action: a maintainer should check these two runs' "Start MCP Gateway" step logs directly and search open issues for existing tracking before filing anything new.38275493621). Single isolated occurrence, below the 2-workflow / 10% threshold for action.38316937103), log shows an orphanedollamaprocess being terminated post-job — consistent with the BYOK/local-model warm-up step being inherently flaky. Single isolated occurrence.No cluster in this window independently meets the "2+ distinct workflows or ≥10% of runs" issue-creation bar with confirmed novel status, so no issue was opened. The Pi CLI and Start MCP Gateway clusters are the closest candidates and are flagged above for manual follow-up once issue search access is restored.
Schedule Heartbeat
245 workflows in this repo declare a
schedule:trigger (241 active, 4 disabled at the gh-aw config level). Checking all 241 active workflows individually against the GitHub Actions API for staleness was not exhaustive given the repo's scale (338 workflows total, 40,000+ historical Actions runs) — this would require up to 241 individual API calls, which was out of budget for this run. The check below covers: (a) the 4 workflows gh-aw reports as disabled, confirmed against the live GitHub Actions API, and (b) the 61 distinct workflows that actually appeared in this run's ~8.5h sample (all healthy/recently active by definition)..lock.ymldaily-geo-optimizer.lock.ymldisabled_manuallydaily-hippo-learn.lock.ymldisabled_manuallyslide-deck-maintainer.lock.ymldisabled_manuallysmoke-ci.lock.ymldisabled_manuallyAll 4 are confirmed
disabled_manuallyvia the live Actions API — this matches gh-aw's own "disabled" status for these workflows, so it is a deliberate/known state rather than an undiagnosed blind spot. No action needed unless a maintainer intends to re-enable them (gh workflow enable <workflow>).No additional blind spots were found among the 237 remaining active scheduled workflows that this run was able to check (cross-referenced against the ~8.5h run sample plus the 4 confirmed-disabled ones above), but this is not a full 241-workflow sweep — a dedicated, budgeted pass (e.g., a stratified sample of daily/sub-daily non-smoke workflows, as done in the 2026-10-09 entry) is recommended to restore full Phase 6 coverage next run.
View per-workflow breakdown (top 30 by failure/run count)
All other workflows observed in the window (33 more) had 0 failures across 1 run each.
Recommendations
search_issues/list_issues/issue_readat all, which blocked Phase 3 entirely and forced a no-issue-creation default out of caution. Investigate the "integrity policy" block ongithub/gh-awissue reads for this workflow's token/permissions.38309913711) and Daily Cache Strategy Analyzer — to confirm whether it's tracked or genuinely new; it's the only cluster this run that doesn't have a clear historical precedent in the trend file.All reactions