Pricing for Remote Config
Stay organized with collections
Save and categorize content based on your preferences.
Starting September 1st 2026, Remote Config will offer a flexible pricing structure designed to accommodate projects of all sizes, featuring both a no-cost plan and a scalable pay-as-you-go tier based on your daily usage.
Only fetch requests invoked directly by the Remote Config service (through client SDKs or REST APIs) contribute to your billed usage. Fetch operations, network calls, or metrics generated internally by other Firebase services don't count toward your Remote Config quotas or billing.
The following table shows the usage per project for both Spark and Blaze plans:
Then:
- 0ドル.000006 per request (0ドル.06 / 10K requests) for usage between 100,001 and 10,000,000 per day.
- 0ドル.000001 per request (0ドル.01 / 10K requests) for usage over 10,000,000 per day.
Transition grace periods for existing projects
This transition grace period is relevant for projects that have Remote Config enabled before September 1, 2026. To ensure a smooth transition to the pay-as-you-go pricing, existing projects are granted the following extended grace periods before the billing enforcement begins:
Bonus: If you upgrade before November 15, 2026, your grace period is extended to 5 months (Billing starts February 1, 2027).
Standard grace periods
This grace period is relevant for projects that have Remote Config enabled on or after September 1, 2026. This includes existing Remote Config enabled projects (created before September 1, 2026) where the transition grace period has expired. If a project exceeds 100,000 fetch requests usage per day, the following actions must be adhered to:
Best practices to optimize usage
To optimize usage, do any of the following:
- Client fetch intervals: Avoid setting very low minimum fetch
intervals (for example,
setMinimumFetchIntervalInSeconds) in production builds. The default recommended interval is 12 hours. - Caching for non-critical parameters: For stable configuration values that
rarely change, consider increasing
setMinimumFetchIntervalInSecondsfrom the default 12 hours to 24 or 48 hours. - App startup fetch loops: Ensure your app doesn't trigger a remote fetch on every screen transition, activity resume, or component render. Use loading strategies like Fetch and activate on load or Activate behind loading screen responsibly.
- Auditing background and inactive fetches: Review background worker jobs, services, or legacy app modules to remove redundant fetch calls ("ghost fetches") that trigger when the app is in the background or inactive.
- Monitoring: Use Google Cloud console and Firebase console pricing and usage dashboards to set up automated billing alerts when daily fetch volumes approach 100,000 requests.
FAQ and troubleshooting
What is the new Remote Config pricing structure taking effect on September 1, 2026?
Remote Config is moving to a usage-based pricing structure with a no-cost tier:
- Spark (No-cost) Plan: Up to 100,000 fetch requests per day at no cost.
- Blaze (Pay-as-you-go) Plan: No-cost for the first 100,000 daily fetch
requests, then:
- 0ドル.06 per 10,000 requests (0ドル.000006/req) between 100,001 and 10,000,000 requests per day.
- 0ドル.01 per 10,000 requests (0ドル.000001/req) for usage over 10,000,000 requests per day.
- Features: All advanced features (Personalization, Rollouts, and A/B Testing integration) remain included across both Spark and Blaze plans at no additional cost.
Do I need a billing account to get started with Remote Config?
No. You don't need a billing account to get started with Remote Config. You can use the Spark plan to get started at no cost. A billing account is only required when you upgrade your project to the Blaze plan to support more than 100,000 daily fetch requests.
Do I need to update my code or upgrade the Remote Config SDK?
No. You don't need to modify your code or update the Remote Config client SDK when transitioning between the Spark and Blaze plans. The tier transition and request metering are handled automatically by the Remote Config backend.
What exactly qualifies as a billable fetch request?
A fetch request occurs whenever your client application or backend server
calls the Remote Config server to check for updated parameter values
(for example, invoking fetch() or
fetchAndActivate() in the client SDKs, or retrieving
templates using REST/Admin SDKs). Only fetch requests invoked directly by
the Remote Config service (through client SDKs or REST APIs) contribute
to your billed usage. Fetch operations, network calls, or metrics generated
internally by other Firebase services don't count toward your Remote Config
quotas or billing.
- Realtime Remote Config: Opening a realtime connection doesn't generate continuous individual fetch requests; however, when the server pushes an invalidation notice, the resulting client call to download the updated configuration counts as a fetch request.
- Cached values: Using cached values already stored on the device
(reading from disk/memory using
activate()orgetString()) doesn't generate a network call or count as a fetch request.
What happens if my project is on the Spark plan and exceeds 100,000 daily fetch requests? How do I upgrade?
- 30-Day Grace Period: When your Spark project exceeds 100,000 daily fetch requests for the first time, Firebase grants a 30-day grace period. During this time, your Remote Config requests will continue to be served without interruption.
- Countdown continuity: The 30-day grace period starts the very first time your project exceeds 100,000 daily fetch requests. This 30-day countdown doesn't pause or reset even if your daily usage temporarily drops below the 100,000 request limit during that timeframe.
- Quota notifications: As your daily fetch volume approaches and reaches the 100,000 quota, project administrators receive automated email alerts and console banner notifications.
- Throttling Risk: If you don't upgrade to the Blaze plan by the end of the 30-day grace period, Remote Config service throttling will begin for requests exceeding the 100,000 daily limit, which may prevent clients from receiving updated configs.
- How to upgrade: You can upgrade to the Blaze plan in the Firebase console to ensure uninterrupted service. Upgrading to the Blaze plan links your project to a Google Cloud Billing account.
Users are not receiving new Remote Config parameter values. Could this be related to pricing or quotas?
Yes. If your project is on the Spark plan, has exceeded the 100,000 daily request limit, and the 30-day grace period has expired, incoming requests over the daily threshold are throttled by the server. Check your usage metrics in the Firebase console and upgrade to the Blaze plan if your daily active users require more than 100,000 daily fetches.
How can I see my current usage to estimate my bill?
In the Firebase console:
- Spark plan: You can track your daily fetch usage on the Usage and billing dashboard. Under the Remote Config section, the Quota Progress Card displays your daily fetch count relative to the 100,000 daily no-cost limit.
- Blaze plan: The Usage and billing dashboard features a tiered usage bar chart that visualizes your daily fetch count broken down across pricing tiers (no-cost tier up to 100,000, 100,001 to 10,000,000, and over 10,000,000).
In the Google Cloud console:
- Cloud Billing reports (Blaze plan): You can view cost
management and detailed usage reports in Cloud Billing. For details, see
View your Cloud Billing reports and cost trends.
When filtering by SKU, choose the SKU based on when your project was created:
- Projects created on or after September 1, 2026:
- SKU ID:
37B1-4623-6F54 - SKU Name: Fetch Requests
- SKU ID:
- Projects created before September 1, 2026:
- SKU ID:
598C-0184-404A - SKU Name: Fetch Requests
- SKU ID:
- Projects created on or after September 1, 2026:
- Quotas & System Limits (Spark and Blaze plans): You
can monitor your current usage and active system limits on the
Quotas & System Limits page. For details, see
View and manage quotas. When filtering reports,
ensure you select the specific Firebase API you want to check quotas for
(for example,
firebaseremoteconfig.googleapis.com).