[workflow-analysis] Weekly Workflow Analysis — week ending 2026-06-29 #42229
Closed
Replies: 1 comment
-
|
This discussion was automatically closed because it expired on 2026-06-30T11:07:53.765Z.
|
Beta Was this translation helpful? Give feedback.
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.
-
Snapshot of agentic workflow activity in
github/gh-aw. Thelogstool times out (60s server deadline) above ~40 runs, so the fleet-wide figures below are a 40-run window (2026-06-29 09:13–10:31, ~8.1h of compute), and the reliability deep-dive is a true 7-day window for the only workflow that failed.Key metrics (40-run window)
Reliability — one failure hotspot
PR Description Updater: 2 failures / 20 runs over 7 days (10%). Both failures landed exclusively on
signed/jsweep/*branches (unified-timeline,ai-credits-context); all 18 non-jsweep runs passed. This is a deterministic branch-class pattern, not random flake. Both failed runs were read-only (no safe outputs emitted) and burned ~10k tokens / ~7–10 min before erroring — wasted spend.Failure detail
signed/jsweep/unified-timelinesigned/jsweep/ai-credits-contextsigned/jsweep/strongly suggests the workflow mishandles auto-generated/signed bot branches.Performance / resource usage
Top action-minute consumers (review-class workflows dominate):
Three skills/quality reviewers consume ~180 action-min combined — the largest cost center. PR Description Updater alone averages ~9 min/run.
Optimization opportunities
signed/jsweep/*) so it stops failing and wasting ~8 min + tokens per jsweep PR. Fixes the only recurring failure.claude-haiku-4-5/gpt-4.1-miniwould cut per-run cost.logs --count > ~40exceeds the 60s deadline, blocking true week-wide fleet analysis — raise the timeout or add pagination.References: §28363364071 · §28318796220 · §28365689771
Beta Was this translation helpful? Give feedback.
All reactions