Quotas and limits

Like other Firebase services, Cloud Functions for Firebase provides a free "Spark" plan and a fixed-price "Flame" plan with quotas appropriate for development or for smaller-scale deployments. See pricing plans for full detail on Spark and Flame quotas and limits. The rest of this page details the scalable, usage-based limits for the "Blaze" plan.

Quotas for Google Cloud Functions encompass 3 areas:

Resource Limits

These affect the total amount of resources your functions can consume.
Time Limits

These affect how long things can run.
Rate Limits

These affect the rate at which you can call the Cloud Functions API and/or the rate at which resources can be used. You can think of rate quotas as "resources over time."

The different types of limits are described in more detail below.

Resource Limits

Quota	Description	Limit	Can be increased	Scope
Number of functions	The total number of functions that can be deployed per project	1,000	No	per project
Max deployment size	The maximum size of a single function deployment	100MB (compressed) for sources. 500MB (uncompressed) for sources plus modules.	No	per function
Max uncompressed HTTP request size	Data sent to HTTP Functions in an HTTP request	10MB	No	per invocation
Max uncompressed HTTP response size	Data sent from HTTP functions in an HTTP response	10MB	No	per invocation
Max event size for background functions	Data sent in events to background functions	10MB	No	per event
Max function memory	Amount of memory a function can use	2048MB	No	per function

Time Limits

Quota	Description	Limit	Can be increased	Scope
Max function duration	The maximum amount of time a function can run before it's forcibly terminated	540 seconds	No	per invocation
Max build time	The maximum time allowed for all builds. Function builds happen at deploy time.	120 minutes per day	Yes	per project

Rate Limits

Quota	Description	Limit	Can be increased	Scope
Function invocations per second	The number of function invocations in a second. If exceeded, all functions will be paused until the next quota period	100,000,000 per 100 seconds	Yes	per region
GHz-seconds	The number of GHz-seconds consumed by all running functions. For example, a function with 256MB memory, which corresponds to 400MHz CPU (see pricing for compute time), will consume 0.4 GHz-seconds if is running for 1 second. The time of a running function is rounded up to a multiple of 100ms.	100,000 GHz-seconds per 100 seconds	Yes	per region
Daily GHz-seconds	The number of GHz-seconds consumed by all running functions, per day.	10,000,000 GHz-seconds per day	Yes	per project
API calls (READ)	Calls to describe or list functions via the Cloud Functions API	5000 per 100 seconds	Yes	per project
API calls (WRITE)	Calls to deploy or delete functions via the Cloud Functions API	80 per 100 seconds	No ¹	per project
API calls (CALL)	Calls to the "call" API	16 per 100 seconds	No ²	per project
Inbound Socket Data	Data transfer into all running functions. For example, data used by a function downloading a file from Google Cloud Storage would count towards this limit.	10 GB per 100 seconds	Yes	per region
Outbound Socket Data	Data transfer out of all running functions, excluding HTTP response data	10 GB per 100 seconds	Yes	per region
Socket connections	The attempts to establish a new outbound socket connection	1,000,000 per 100 seconds	Yes	per region
DNS resolutions	The attempts to resolve a domain name in DNS; cached results do not count towards this quota	40,000 per 100 seconds	Yes	per project

Scalability

Cloud Functions invoked by HTTP scale up quickly to handle incoming traffic, while background functions scale more gradually. A function's ability to scale up is dictated by a few factors, including:

The amount of time it takes for a function's execution to complete (short-running functions can generally scale up to handle more concurrent requests).
The amount of time it takes for a function to initialize on cold start.
Rate limits, as described above.
Your function's error rate.
Transient factors, such as regional load and data center capacity.

Background functions have additional limits, as explained below. These limits do not apply to HTTP functions.

Additional quotas for background functions

Quota	Description	Limit	Can be increased	Scope
Max concurrent invocations	The maximum concurrent invocations of a single function Example: if handling each event takes 100 seconds, the invocation rate will be limited to 10 per second on average	1,000	No	per function
Max invocation rate	The maximum rate of events being handled by a single function Example: if handling an event takes 100ms, the invocation rate will be limited to 1000 per second even if only 100 requests, on average, are handled in parallel	1000 per second	No	per function
Max concurrent event data size	The maximum total size of incoming events to concurrent invocations of a single function Example: if events are of size 1MB and processing them takes 10 seconds, the average rate will be 1 event per second, because the 11th event will not be processed until processing one of the first 10 events finishes	10MB	No	per function
Max throughput of incoming events	The maximum throughput of incoming events to a single function Example: if events are of size 1MB, then the invocation rate can be maximum 10 per second, even if functions finish within 100ms	10MB per second	No	per function

When you reach a quota limit

When a function consumes all of an allocated resource, the resource becomes unavailable until the quota is refreshed or increased. This may mean that your function and all other functions in the same project will not work until then. A function returns an HTTP 500 error code when one of the resources is over quota and the function cannot execute.

To increase quotas above the defaults listed here, go to the Cloud Functions Quotas Page, select the quotas you want to modify, click EDIT QUOTAS, supply your user information if prompted, and enter the new quota limit for each quota you selected.

Quota limits for Firebase CLI deployment

For each function that the Firebase CLI deploys, these types of rate and time limits are affected:

API calls (READ) - 1 call per deployment, no matter how many functions
- Limit: 5000 per 100 seconds
API calls (WRITE) - 1 call per function
- Limit: 80 per 100 seconds
Max build time - A few minutes per function depending on size
- Limit: 120 minutes per day