Git LFS "This repository is over its data quota" (429) in CI

The LFS server rejected the fetch because the account is over its monthly storage or bandwidth allowance. GitHub returns HTTP 429 on the batch API and the checkout fails before any object downloads.

What this error means

checkout or git lfs pull fails with "This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs" and a "batch response: ... 429" line.

git-lfs

batch response: This repository is over its data quota. Account responsible for
LFS bandwidth should purchase more data packs to restore access.
error: failed to fetch some objects from 'https://github.com/acme/app.git/info/lfs'

Common causes

Monthly LFS bandwidth allowance is exhausted

Every CI run that fetches LFS objects counts against the account bandwidth. Frequent runs on large binaries burn the 1 GB free allowance fast, and the server then answers 429.

LFS storage is over the purchased quota

Storage and bandwidth share the same data pack. If stored LFS objects exceed the quota, new fetches are blocked until more packs are added or usage drops.

How to fix it

Reduce how often CI fetches LFS objects

Cache LFS objects between runs so the same blobs are not re-downloaded every job.
Skip LFS on jobs that do not need the binaries by leaving lfs: false on those checkouts.
Buy additional GitHub data packs if the workload genuinely needs the bandwidth.

.github/workflows/ci.yml

- uses: actions/cache@v4
  with:
    path: .git/lfs
    key: lfs-${{ hashFiles('.lfs-assets-id') }}
- uses: actions/checkout@v4
  with:
    lfs: true

Confirm and raise the quota

Check the LFS usage in the account billing page. Data packs add both storage and bandwidth; add packs or prune large history to get back under the limit.

How to prevent it

Cache .git/lfs so repeated CI runs do not re-spend bandwidth.
Only enable lfs: true on jobs that actually read the tracked binaries.
Watch LFS usage in billing before it hits the allowance.