Skip to main content
Image

r/Firebase



Advertisement: This is what safe looks like. Mazda has been named Consumer Reports’ Safest New-Car Brand. ​
This is what safe looks like. Mazda has been named Consumer Reports’ Safest New-Car Brand. ​
Image This is what safe looks like. Mazda has been named Consumer Reports’ Safest New-Car Brand. ​


Introducing Firebase spend caps for AI Logic, Functions, and App Hosting
Introducing Firebase spend caps for AI Logic, Functions, and App Hosting

If you’ve spent any time on this subreddit (or building on cloud platforms in general), you know the persistent anxiety around runaway bills from a recursive loop, a viral traffic spike, or an unthrottled API key.

Now, Firebase AI Logic, Cloud Functions for Firebase (1st and 2nd gen), and Firebase App Hosting all let you set spend caps that pause the service after you reach 100% of a configured threshold!

You set spend caps per-service in a single spot in the Firebase console, receive automated email alerts at 50%, 80%, and 100% of a spend cap threshold, see a banner in the console if a service is paused, and can lift spend caps after they're enforced if you need to turn a service back on.

Note that due to latency in usage reporting, spend cap enforcement is not instantaneous and can be delayed by several minutes, and any cost overages incurred during this delay will be billed as normal. Even though they're not instant, spend caps can catch runaway bills much earlier than before.

Spend caps are an emergency circuit breaker, but they work best alongside Budget Alerts, App Check, API key restrictions, and IAM to help avoid surprise bills.


Mobile app events drop after first journey on Release build when sGTM toggle enabled but work on debugView — Front Door returns 204, F5 no blockers but no hits land on sGTM
Mobile app events drop after first journey on Release build when sGTM toggle enabled but work on debugView — Front Door returns 204, F5 no blockers but no hits land on sGTM

Post Body:

Hey everyone,

We are running into a perplexing issue with Firebase Analytics / GA4 mobile event tracking when routing app events through a Server-Side Google Tag Manager (sGTM) endpoint. We need some fresh eyes on this after i tried all AI suggestions etc!

The Problem:

When we enable the sGTM endpoint toggle in our app/data stream, events stop reflecting on the GA4 Realtime dashboard in Release builds.

Here is the exact behavior:

  1. Debug build on Android/Firebase DebugView / sGTM Preview mode: Everything flows perfectly! The GA4 - App client claims the payloads, tags fire, and events land in GA4 Realtime as expected.

  2. Release builds: The initial journey (e.g., Biometric Enablement / App Launch) lands on sGTM and GA4 fine. However, all subsequent journeys/events after that first journey fail to land on sGTM entirely.

  3. When sGTM toggle is DISABLED: All events across every journey flow normally to GA4 directly via standard SDK endpoints in both Debug and Release builds.

Network & Infrastructure Context:

  • Initial Blocker: We initially discovered that our F5 WAF had payload size limits blocking traffic, which we increased.

  • Front Door Behavior: Azure Front Door logs show 204 No Content status codes for requests hitting the endpoint, indicating the edge layer receives and accepts the traffic.

  • The Missing Link: Despite Front Door returning 204, subsequent events after the first journey never actually land on the sGTM container at all.

What We Have Verified:

  • sGTM Client: Active GA4 - App Client installed.

What We Suspect:

Since initial events hit sGTM but all subsequent app events vanish before reaching sGTM in Release builds:

  • Is the Firebase SDK / GTM SDK failing or halting batching/dispatching after the first request when sending to a custom sGTM URL in Release mode?

  • Could R8 / ProGuard code minification / stripping be breaking the internal queuing/serialization mechanism of the Firebase event dispatch thread in Release builds?

  • Is there an issue where session state, SSL connection reuse, or custom endpoint URL persistence breaks inside the mobile client after the first HTTP call?

Has anyone encountered a scenario where the first mobile journey events reach sGTM cleanly, but all subsequent journey events are completely dropped on the client side before hitting sGTM in Release builds?

Any insights, SDK dispatch debugging tips would be immensely appreciated!

Thanks!