r/Firebase

Firebase Hosting served 54 GB after I undeployed the site and monthly quota reset — how is this possible?

I’m trying to understand unexpected Firebase Hosting bandwidth usage across two billing cycles and whether anyone else has seen something similar.

During March, my Firebase Hosting downloads suddenly jumped to about 859 GB, which resulted in charges of roughly ₹11,357. The project is still early-stage with very limited real users, so this traffic level doesn’t make sense from normal usage.

As soon as I noticed the spike, I undeployed the site from Firebase Hosting to stop further traffic.

However, after the quota reset on April 1, I saw another 54 GB of downloads recorded within a single day, even though the site had already been undeployed before the reset. I expected usage to drop to zero once hosting content was removed.

That’s the part I can’t explain.

What I’ve checked so far:

  • Site was undeployed before the new billing cycle began
  • No new deployment was made in April
  • Traffic still appeared immediately after quota reset
  • This is a static hosting setup (no intentional large asset delivery)
  • No marketing campaigns or traffic spikes occurred
  • Real user traffic is minimal

So my current guesses are:

  • cached CDN edge responses still being served globally
  • asset hotlinking from another site
  • bots repeatedly requesting previously indexed URLs
  • some Firebase Hosting behavior I don’t fully understand yet

Has anyone seen bandwidth continue after undeploy + monthly reset like this?

Is there a way to identify which files were downloaded from Hosting logs?

And is CDN cache delivery counted toward Hosting bandwidth even after removal?

I’ve already contacted Firebase support, but I’m trying to understand whether this is a known pattern or something unusual with my setup.

Any insights would really help.

https://preview.redd.it/m8ohlzginqtg1.png?width=1671&format=png&auto=webp&s=e6dd1e6f4689583a05fe46e212208aeb83001780

reddit.com
u/No-Camel2750 — 1 hour ago

Google Cloud Run asia-south1 stuck with "Project failed to initialize in this region due to quota exceeded" for 4 days — quota resets not helping

Been stuck on this for 4 days and nothing is working.

**The situation:**

Migrated Firebase Cloud Functions from us-central1 to asia-south1.

During deployment, hit the write quota limit (30/min in asia-south1 —

yes, it's tiny). Now ALL 41 Cloud Run services in asia-south1 show:

"Routing traffic: Failed. Project failed to initialize in this region

due to quota exceeded."

**What makes this weird:**

- Code uploaded successfully every time

- The services EXIST in Cloud Run

- Daily quota reset happens — doesn't fix it

- Even `gcloud run services update-traffic myservice --to-latest

--region asia-south1` fails with the same quota error

- `firebase deploy --only functions` says "Skipping unchanged functions"

because code hash didn't change

**What I've tried:**

- Waited for daily quota reset (midnight Pacific) — same error

- Tried gcloud update-traffic directly — same error

- Tried forcing redeploy with code change — quota error again

- Deleted unrelated service to free region slot — same error

- Filed support case — waiting

**My understanding:**

The services are stuck pointing at failed revisions. Fixing them

requires Cloud Run write operations. But those writes are being

throttled. So it's a deadlock — can't fix the quota state without

quota.

**Questions:**

  1. Has anyone recovered from this without Google support intervening?

  2. Is there a way to force Cloud Run to serve traffic from an existing

    revision without using the write quota?

  3. How long does the project-level throttle typically last after

    repeated quota exhaustion?

Project: Firebase Functions v2 (Cloud Run), asia-south1, Node.js 22

Any help appreciated — this is blocking a production app launch.

reddit.com
u/PlanBot_ — 20 hours ago
Week