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

By Kaveh Alemi·Latchkey

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.

Using this in CI

CI checkouts are shallow and detached by default, which changes the answer this command gives you. Commands that read history, branch names, or tags need the checkout configured for it.

.github/workflows/ci.yml

- uses: actions/checkout@v4
  with:
    fetch-depth: 0   # history, tags, and git describe all need this

- run: |
    git rev-parse --is-shallow-repository   # expect false
    git rev-parse --abbrev-ref HEAD          # prints HEAD when detached

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.

Frequently asked questions

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

There are 2 common causes: monthly lfs bandwidth allowance is exhausted and lfs storage is over the purchased quota. Every CI run that fetches LFS objects counts against the account bandwidth.

How do I fix Git LFS "This repository is over its data quota" (429) in CI?

There are 2 fixes depending on which cause you have: reduce how often ci fetches lfs objects and confirm and raise the quota. Work through them in order, since the first is the most common.

What does Git LFS "This repository is over its data quota" (429) in CI actually mean?

checkout or git lfs pull fails with "This repository is over its data quota.

How do I stop Git LFS "This repository is over its data quota" (429) in CI happening again?

Cache .git/lfs so repeated CI runs do not re-spend bandwidth. The prevention section lists 3 changes that keep it from recurring.