The Deploy Blocked by GitHub's Organization Quota, Not Your Code

The deploy had been dead all night. Not a code error, not a failed test: a GitHub Actions billing block, silent from inside the repo and only visible on GitHub’s org settings page. Fixing it took one commit, and it wasn’t a code change.

The false trail

Two overnight triage passes had already misdiagnosed it. A ci-alert/triage session at 12:26 AM read the failing deploy log, saw BlobNotFound: the specified blob does not exist, and called it a Cloudflare Pages storage or cache problem, a stale build artifact blob expired out from under the deploy step. A second pass 20 minutes later landed on the same theory with slightly different wording: Azure/CDN blob storage error, source unclear. A third pass at 2:26 AM and a fourth at 2:42 AM repeated the same conclusion. Four separate triage runs, four confident-sounding root causes pointing at blob storage, and none of them were it.

BlobNotFound was a real error, but it was downstream. It’s what a Pages deploy step looks like when the workflow run that was supposed to produce the artifact never actually executed, because GitHub had already refused to schedule it. The triage agents were reading the last log line the runner managed to emit before the job got starved, not the actual failure. There was no separate blob storage subsystem to debug. The job that would have written the blob never got a runner.

The same failure mode had shown up hours earlier on a different repo the same day: a client billing platform we run CI for also hit a dead queue, traced that morning to the shared free CI allowance running out. Two repos, same account, same day, same starvation. That repetition is what made the actual cause legible: this wasn’t a Cloudflare quirk, it was one number running out.

What the quota actually is

GitHub’s free tier for Actions minutes is allocated per plan, and a personal free account has one shared pool of minutes across every repository that account owns. It doesn’t matter how unrelated the repos are. dxdev.com’s static site build and an internal CRM’s CI suite were drawing from the same account level allowance, and once other repos on that account had burned through it for the billing period, every subsequent workflow run queues against a quota that’s already at zero. GitHub doesn’t fail loud with a “quota exceeded” status on the commit. It just doesn’t run the job, or runs it and starves it partway through, and whatever step was mid-flight when the throttle hit is what shows up in the log as the error, in this case a blob lookup with nothing to find.

There’s no per-repo override on a free personal account. You can’t ring-fence one project’s Actions minutes from the rest of your account. The three options were: upgrade to a paid plan and buy more minutes, self-host a runner so the jobs stop drawing from GitHub’s pool at all, or move the repo somewhere the allowance resets. Buying minutes fixes it for the one account, permanently coupling every future side project’s CI health to whatever else that account happens to be running. Self-hosting a runner is real infrastructure to babysit for a static site build. Moving the repo into its own GitHub organization gives it a completely separate free Actions allowance, because the allowance is scoped to the plan owner, and an org is its own plan owner, distinct from any personal account.

The fix and the check

The fix was moving the dxdev.com repository into a new dedicated GitHub organization, which gets its own zeroed-out Actions minutes independent of whatever the personal account or any other org had already spent. No code in the repo changed. The workflow YAML was already correct; it had been queuing against a pool with nothing left in it. Once the repo lived under the new org, the next push triggered a workflow run against a fresh allowance, and that deploy succeeded on the first try.

The diagnostic lesson is the gap between “the log shows an error” and “the log shows the failure.” Four automated triage passes correctly transcribed what the log said and still missed the cause, because the log only contains what the starved job managed to emit before it stopped getting scheduled. The tell, in retrospect, wasn’t in that repo’s log at all. It was the second, unrelated repo hitting the identical wall the same day. One instance of BlobNotFound looks like a storage bug. Two unrelated repos going dark on the same account, same day, is a quota.

dxdev LESSON · paste into your AI coding agent
LESSON: A starved job's log only shows the last thing it managed to emit before it stopped running, not why it stopped
SOURCE: dxdev.com/blog/2026-08-29_github-actions-allowance-per-organization-not-account
WHAT HAPPENED: A deploy failed overnight with a storage-lookup error, and four separate automated triage passes over several hours all confidently diagnosed it as a caching or blob-storage bug, because that is exactly what the failing log line said. The real cause sat one level above the code: a personal account's shared CI-minutes quota, pooled across every repository that account owned regardless of how unrelated they were, had run out, so the workflow run that would have produced the missing artifact never actually got scheduled, and the log only captured the last line the deploy step managed to print before it was starved mid-flight. The actual tell was not in that repository's log at all, it was a second, completely unrelated repository on the same account hitting an identical dead queue the same day, which made a single confusing storage error legible as one account, one shared number, run out. The fix required no code change: moving the affected repository into its own dedicated organization gave it a separate, independent CI-minutes allowance, since that allowance is scoped to whoever owns the plan and an organization is its own distinct plan owner, rather than paying for more minutes on the original account, which would permanently couple every future unrelated project's CI health to whatever else that account happened to be running.
THE RULE: A log only contains what a process managed to emit before it stopped running, not necessarily why it stopped; when an error looks like it points at a specific subsystem but the real root cause is starvation or throttling one level above the code, such as a shared quota, the log will confidently misdirect every reader toward the wrong layer, and the real tell is often a second, unrelated failure sharing the same account or resource, not a deeper read of the first failure's log.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any CI or deploy failure diagnosed purely from its log's error message, without checking whether the job that produced that log actually got scheduled and ran to completion.
      2. Any shared resource pool, such as a billing account's CI minutes or a rate limit, spanning multiple unrelated projects, where one project's consumption can silently starve another's.
      3. Two or more unrelated systems failing in a similar way on the same day or account being investigated as separate incidents rather than checked for a shared underlying resource constraint.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.