Quotas

This document describes the quota limits for Google Cloud Functions.

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

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."

Time Limits

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

Max inactivity time for background functions

The maximum amount of time that a background function can be kept
without any invocation. Functions that are not invoked even once during
this time may enter a state in which new events will not trigger them
anymore. If this happens, such functions have to be redeployed to start
working again.Note: This inactive state is not reflected in the UI, CLI, or API
in any way.

30 days

No

per function

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

1,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

Yes

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.

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

Max concurrent invocations for a background function

The maximum concurrent invocations of a single function that
is not triggered by HTTP requestsExample: 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 for a background function

The maximum rate of events being handled by a single function that
is not triggered by HTTP requestsExample: 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 for a background function

The maximum total size of incoming events to concurrent invocations of
a single function that is not triggered by HTTP requestsExample: 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 for a background function

The maximum throughput of incoming events to a single function that
is not triggered by HTTP requestsExample: 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

Scalability

Cloud Functions invoked by HTTP scale quickly to the desired invocation
rate, while background functions scale more gradually. In the latter case,
scalability depends on the duration of functions, and longer functions will
scale slightly slower.

For any function type, the maximum scalability is limited by the
Rate Limits described above. Note that some of
the limits apply to each individual function and can be dealt with by deploying
multiple functions, while others apply to the entire project.

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.