Run This Remote Config Fetch Check Before Your Weekend App Gets Throttled

You ship a weekend app with a kill switch, then notice Remote Config in the Firebase console. The flags are handy, but the fetch math makes you wonder whether a small app can quietly become a bill.

With the default 12-hour minimum fetch interval, a device can fetch no more than twice per day, making 50,000 daily active users the break-even point for the free tier under that default. The free tier covers 100,000 fetch requests each day, so most projects should not be affected. Most side projects stay side projects, and that is fine. A short check answers the worry before throttling or billing starts.

Remote Config begins its pay-as-you-go pricing model on September 1, 2026. The number to watch is daily fetch volume, not user count. A fetch happens when a client app or backend server asks the Remote Config server for updated parameter values, including calls such as fetch() or fetchAndActivate() from client SDKs. When your app calls the client library on launch, on resume, and after every deep link, the number can climb faster than your user count.

The free ceiling turns on fetches, not users

The default interval makes the math forgiving for small apps. It keeps each device from turning a normal day into a stream of requests. Below the break-even point, the math is on your side. Above it, the flags are doing real work and the cost question is real too.

Use the busiest recent day, not a calm average. A launch day, a push campaign, or a bug that relaunches the app can all push the number higher than your normal user count. The check is a way to see that spike before it becomes a quota surprise. A still-small app may not show the difference. A growing app makes the difference the whole point of the check.

A short check turns worry into a number

Keep this list in the README next to the deploy script. The order matters because it turns a vague worry into a number. It is short enough to run before a release, and specific enough to tell you what to change.

• Read the daily Remote Config fetch total in the Firebase console.
• Multiply daily active users by the maximum fetches per device per day.
• Compare that product with the daily allowance.
• Check the minimum fetch interval and raise any development-time value below the production value.
• If the project is on Spark and over the cap, note that the server throttles additional requests above the daily cap after a 30-day grace period.

The point is to know which outcome you are in: safe, raise the interval, or plan for Blaze and grace-period timing. The check is short because the risk is narrow: a small app starts behaving like a large product before the console tells you so.

The fetch interval is the first lever

When the estimate is close to the allowance, the first fix is usually the interval. Changing the interval is the cheapest lever because it changes how often the app asks, not what it asks for. A shorter interval during development can make a handful of testers behave like a crowd. Restore the production interval before you share the build. That change can keep a small app under the line without touching the code that reads flags.

Being over the cap is not a permanent lock today. You can still reduce fetch volume, or move to a paid plan when the app is worth the spend.

Under the Blaze plan, Remote Config costs $0.06 for each 10,000 requests through 10 million requests, and $0.01 for each 10,000 requests after 10 million. For a weekend project, that is usually a small bill, but it is a bill. An early-stage app may still be better served by the interval and user-count math.

Existing projects have a timing lever. Upgrading before November 15, 2026 extends the grace period to five months, with billing starting February 1, 2027. The window can buy time for a project not ready to pay, and it can make the switch less abrupt for one that is.