LFS usage increased 1GB in a day without any changes to repos

[h8ku]

Select Topic Area

Question

Body

I tried doing an export of a usageReport and the data there does not match what billing says. The site doesn't show LFS by repo anymore.

Yesterday I got an e-mail

[GitHub] You have used 90% of the Git LFS storage included

Today I got another e-mail

[GitHub] You have used 100% of the Git LFS storage included

A 1GB increase without any changes to repo files.

When I exported the usageReport I compared the git_lfs git_lfs_storage for repos in our org per day and their quantity did not change. So what's going on? How does LFS usage go up in a day without any repos being changed? Phantom files somewhere somehow? A bug with github and LFS storage totals? How can I figure out where the actual usage is? Is there an audit log somewhere for LFS changes?

[Akitha-Chanupama]

Git LFS storage can increase even if you didn’t change any files in the repository. A few things can cause this:

• New LFS objects pushed in the past becoming fully processed – sometimes storage usage updates after background processing.
• Force pushes or history rewrites that previously added LFS objects but were not immediately reflected in the billing report.
• Multiple versions of the same file stored in LFS. Even if the latest file looks the same, every new version counts as a separate object.
• Forks or other repositories in the organization referencing the same LFS objects.
• Delayed billing/usage reporting, where the email alert reflects updated totals before the usage report refreshes.

Unfortunately, GitHub does not provide a very detailed per-object audit log for LFS storage changes, so it can be difficult to track exactly which files increased usage.

To investigate further you can try:

• Running git lfs ls-files in each repository to list tracked LFS files.
• Checking recent pushes or CI workflows that may have uploaded artifacts tracked by LFS.
• Reviewing repositories in the organization that might also be using LFS.

If the usage reports still do not match the billing numbers after some time, it may be worth contacting GitHub Support with the usage report and timestamps so they can verify whether it is a reporting delay or a billing issue.

[MaheshSharan]

Hey man , I think LFS storage doesn’t only increase when files change.
It increases when new LFS objects are uploaded, and those objects stick around even if history is rewritten or the file is removed.

A few common causes:
• force pushes / rewritten history
• CI accidentally uploading artifacts
• someone committing a large file again (creates a new LFS object)
• usage coming from another repo in the org
• delayed billing accounting

Sadly GitHub doesn’t provide a great audit log for LFS objects, so tracking the exact source can be tricky.

[aman8637]

Yes, you’re mostly right.

Git LFS storage increases whenever a new LFS object is uploaded, not only when files change in the repo. Even if the file is deleted later or the history is rewritten, the old LFS objects usually remain stored on GitHub, so storage usage keeps growing.

Some common reasons this happens are:

Force pushes or rewritten history, which remove commits but not the LFS objects.

CI pipelines uploading build artifacts or large files by mistake.

Re-committing a large file, which creates a completely new LFS object even if the filename is the same.

Another repository in the same organization using the shared LFS storage.

Delayed billing updates, where usage appears later than when it was actually uploaded.

Unfortunately, GitHub doesn’t provide a detailed audit log for LFS objects, so it can be difficult to identify exactly where the extra storage came from.

[nmtoan91]

I got the same email.
Even though I didn't touch the repos that use LFS.

[livedtrid]

Same here. I received the same email, the size is increasing by the hour. I'm not even using github in my projects. I think it should be some sort of bug.

[pascaldisse]

Same issue here, also received the same emails yesterday and today. Haven't even touched github in 6 months.

[h8ku]

How can we escalate this to someone at github so they can see what's going on...

[ash-iiiiish]

Helping with Questions and Answers
Read 9 web pages
Here is a clear, step-by-step summary to help the user resolve their mysterious Git LFS usage increase and billing discrepancy.

Summary of the Problem
You are experiencing an unexplained 1GB increase in Git LFS storage usage on GitHub within 24 hours, despite no changes to your repository files. Your exported usage report shows no change in git_lfs_storage per day, yet billing indicates you have hit 100% of your quota. You are looking for an audit log or a way to track down where this phantom usage is coming from.

Root Cause Analysis
Based on similar recent reports from other GitHub users, the issue is highly likely caused by GitHub's migration to a new billing platform, not by actual file changes or a bug in storage totals .

New Billing System: GitHub is transitioning accounts from the old "Data Packs" model to a new platform where billing is based on actual usage and managed via budgets .

Default Budget of $0: For many accounts migrated to this new system (especially free organizations), the default budget for LFS is set to $0 . This means that if your usage exceeds the new, increased included limit for your plan, the budget stops all access and reports the account as over-quota, even if your actual stored data hasn't changed.

UI Discrepancy: This transition explains why you cannot see a per-repo breakdown in the billing UI anymore; the interface has changed for many users . The usage report export might still show old data or be cached, while the billing system reflects the new budget enforcement.

Step-by-Step Solution Guide
Here is how to diagnose and fix the issue:

Step 1: Check Your Budget Settings
This is the most likely fix. The unexplained "usage" is likely the system enforcing a new $0 budget.

Navigate to your Organization settings.

Click on Billing and licensing.

Look for a section called Budget and alerts .

Find the budget for Git LFS.

If it is set to $0, this is the problem.

Solution: Either increase the budget to a positive amount (you may need to add a payment method) or uncheck the box that says "Stop when budget exceeded" to disable the limit entirely . This will immediately restore access and stop the false "over quota" alerts.

Step 2: Understand the New Included Usage
Before purchasing, check your new included limits. The new platform offers significantly increased included storage and bandwidth for some plans . You might not need to pay anything if your usage is within these new limits; you just need to adjust the budget to allow it.

Step 3: Request a Manual Cleanup (If Necessary)
If you have actually exceeded your storage due to orphaned or unreferenced LFS objects, the per-repo export might not show them because they are not attached to a specific branch or commit.

Contact GitHub Support: Open a ticket with GitHub Support . Explain that you have cleaned up your repository locally but your LFS quota is still full. They can manually clean up unreferenced Git LFS objects on the remote server for you . This is often the only way to clear space taken up by "phantom" files that are stored in GitHub's backend but not in your current repository tree.

Support Link: You can create a support ticket here: https://support.github.com/contact/account

Step 4: Ask for Account Migration (If on Old System)
If you cannot find the "Budget and alerts" section, your account may not have been migrated yet. In this case, you may be stuck in a limbo where you can't buy old Data Packs and can't use the new budgets .

Contact GitHub Support: Ask them to manually migrate your organization to the new billing platform . Once migrated, you will have access to the budget controls mentioned in Step 1.

How to Find "Phantom" Usage
Audit Logs: There is currently no public-facing audit log specifically for LFS object changes. The most reliable way to get a definitive answer on what objects are consuming space is to ask GitHub Support to run a cleanup or audit of unreferenced objects for you .

Export Reports: The fact that your export report showed no change confirms that the files attached to your current repository commits are stable. The increase is almost certainly coming from a billing policy change or unreferenced objects in the backend.

Summary: The sudden 1GB increase is almost certainly a billing policy enforcement issue, not a data storage issue. The primary fix is to adjust your LFS budget settings to a non-zero value or disable the limit.

[rpm2011]

Thank you!