[api-consumption] π GitHub API Consumption Report β 2026-08-04 #50237
Closed
Replies: 1 comment
|
This discussion has been marked as outdated by GitHub API Consumption Report Agent. A newer discussion is available at Discussion #50540. |
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.
π GitHub API Consumption Report
Report Date: 2026-08-04 Β· Repository: github/gh-aw Β· Run: #30905101531
Today at a Glance
safe_output.jsonl/run_summary.run.safe_items_countentries were present in any collected run β see cache status note below)π GitHub API Calls Trend (90 days)
A 90-day backfill was requested, but the logs tool's available history currently only reaches back to 2026-08-03 β 2 calendar days, 213 runs. Within that window, consumption rose from 105,941 calls (2026-08-03, full day) to 249,489 calls (2026-08-04, partial day, cuts off ~11:22 UTC), so the apparent jump is not a like-for-like daily comparison. No multi-week peaks or spikes can be identified yet β this is effectively the first data point in the trending series.
π GitHub API Calls by Workflow Trend (30 days)
Across both available days, the same eight workflows dominate consumption in a consistent order: PR Sous Chef, Matt Pocock Skills Reviewer, and Test Quality Sentinel lead every day, with the four PR-review/skills-reviewer workflows together accounting for roughly half of total daily quota. This concentration pattern held steady day-over-day, suggesting it's a stable (not anomalous) usage profile rather than a one-off spike β but there are only two days to confirm that from.
π GitHub REST API Calls Heatmap (90 days)
Activity is heavily concentrated in the evening/night UTC hours: the single busiest hour was 2026-08-03 22:00 UTC at 45,309 calls, followed by 23:00 UTC (36,365) and 2026-08-04 01:00 UTC (36,316). A secondary cluster runs roughly 00:00β05:00 UTC. Daytime hours (12:00β19:00 UTC) are comparatively quiet across both days. This is a 2-day snapshot, not a stable weekly pattern β treat the "busiest day of week" question as unanswered until more history accumulates.
π© Top API Burners (24h)
The top 7 named workflows account for just over half (50.4%) of the last 24h's 249,489 calls, with PR Sous Chef alone at 9.2%. The remaining 49.6% ("Other") is spread across dozens of lower-volume workflows β so unlike a classic "one workflow dominates" risk profile, this repo's API load is broadly distributed across its large agentic-workflow fleet, which limits concentration risk from any single workflow.
π GitHub REST API Consumption by Workflow (last 24h)
PR Sous Chef (22,883 calls, 17 runs), Matt Pocock Skills Reviewer (19,692, 14 runs), and Test Quality Sentinel (18,833, 14 runs) are the top three consumers. None are individually close to the 15,000/hr per-token limit on their own, but the peak-hour heatmap above shows combined consumption across concurrently-scheduled workflows reached 45,309 calls in a single hour β worth periodically checking whether any of these workflows share a single GitHub App installation token, since that would be the shared quota that actually throttles.
Top 10 Workflows by REST API Consumption (last 24h)
Failure note: 11 of 213 runs failed (5.2%). PR Code Quality Reviewer failed 3 separate times in the window (runs
30859127480,30861967269,30876479583) β the only workflow with more than one failure. Anauditon run30876479583showed a generic "Workflow Failed" conclusion with a single turn and no tool calls, without a more specific root cause surfaced by the audit tool; worth a manual look if this recurs.Trending Indicators
π¦ Cache Memory Status
/tmp/gh-aw/cache-memory/trending/api-consumption/history.jsonl-90dLog collection notes:
logsMCP tool paginated 3 batches (100 + 100 + 13 runs = 213 total) beforecontinuationreturnednullnaturally β within the allowed 2-additional-continuation-call budget, no calls were skipped due to hitting that budget.safe_output.jsonlfiles orrun.safe_items_countfields were found in any of the 213 collected run directories, so the "Safe-Output Writes" metric above is reported as 0 rather than guessed.Automatically generated by the api-consumption-report workflow.
All reactions