Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
An App Engine application can consume resources up to certain quotas.
You can view the daily usage and quota consumption of App Engine resources for your project in the Google Cloud Platform Console Quota Details page.
Billable limits and safety limits
App Engine has three kinds of quotas or limits:
- Free quotas: Every application gets an amount of each resource for free. Free quotas can only be exceeded by paid applications, up to the application's spending limit or the safety limit, whichever applies first.
- Spending limits: If you are the project owner and the billing administrator, you can set the spending limit to manage application costs in the Google Cloud Platform Console in the App Engine Settings. Spending limits might be exceeded slightly as the application is disabled.
- Safety limits: Safety limits are set by Google to protect the integrity of the App Engine system. These quotas ensure that no single app can over-consume resources to the detriment of other apps. If you go above these limits you'll get an error whether you are paid or free.
Spending limits
If you are a project owner and a billing administrator , you can enable billing for a project so that it can use additional resources beyond the free quotas. You will be charged for the resources your application uses above the free quota thresholds.
After you enable billing for your application, you might want to set a spending limit so there is an approximate limit to the amount you can be charged per day. By default, the spending limit is unlimited, so it's a good idea to specify a spending limit to gain more control over application costs. Note that spending limits might be exceeded slightly as the application is disabled.
When you enable billing for your application, the application's safety limits increase. See the Resources section for details.
Safety limits
Safety limits include daily quotas and per-minute quotas:
- Daily quotas are refreshed daily at midnight Pacific time. Paid applications can exceed this free quota until their spending limit is exhausted, or until the safety limit is reached, whichever comes first.
- Per-minute quotas protect the application from consuming all of its resources in very short periods of time, and prevent other applications from monopolizing a given resource. If your application consumes a resource too quickly and depletes one of the per-minute quotas, the word "Limited" appears next to the appropriate quota on the Quota Details screen in the GCP Console. Requests for resources that have hit their per-minute maximum will be denied.
See When a Resource is Depleted for details about what happens when a quota is exceeded and how to handle quota overage conditions.
Tip: For paid apps, the maximum per-minute quotas accommodate high
traffic levels, enough to handle a spike in traffic from your site getting
mentioned in news stories. If you believe a particular quota does not meet
this requirement, submit
feedback in the issue tracker. Note that filing feedback is not a
request for increasing your quota, but it will help us understand which quota
is potentially too low for general use
cases.
If you're expecting extremely high traffic levels, or for some
reason your app requires particularly high quotas (e.g. because of significant
product launch or large load tests), we recommend you sign up for a support package.
How resources are replenished
App Engine tracks your application's resource usage against system quotas. App Engine resets all resource measurements at the beginning of each calendar day (except for Stored Data, which always represents the amount of datastore storage in use). When free applications reach their quota for a resource, they cannot use that resource until the quota is replenished. Paid apps can exceed the free quota until their spending limit is exhausted.
Daily quotas are replenished daily at midnight Pacific time. Per-minute quotas are refreshed every 60 seconds.
When a resource is depleted
When an application consumes all of an allocated resource, the resource becomes unavailable until the quota is replenished. This may mean that your application will not work until the quota is replenished.
For resources that are required to initiate a request, when the resource is
depleted, App Engine by default returns an HTTP 403 or
503 error code for the request instead of calling a request
handler. The following resources have this behavior:
- Bandwidth, incoming and outgoing
- Instance hours
Tip: You can configure your application to serve a custom error page when your application exceeds a quota. For details, see the configuration file reference for Python (2.7, 3.7), Java, Go, PHP (5.5, 7.2), or Node.js .
For all other resources, when the resource is depleted, an attempt in the application to consume the resource results in an exception. This exception can be caught by the application and handled, such as by displaying a friendly error message to the user. In the Python API, this exception is apiproxy_errors.OverQuotaError. In the API for Java, this exception is com.google.apphosting.api.ApiProxy.OverQuotaException. In the Go API, the appengine.IsOverQuota function reports whether an error represents an API call failure due to insufficient available quota.
The following example illustrates how to catch the OverQuotaError, which may be raised by the SendMessage() method if an email-related quota has been exceeded:
try:
mail.SendMessage(to='test@example.com',
from='admin@example.com',
subject='Test Email',
body='Testing')
except apiproxy_errors.OverQuotaError, message:
# Log the error.
logging.error(message)
# Display an informative message to the user.
self.response.out.write('The email could not be sent. '
'Please try again later.')
Is your app exceeding the default limits? If you need a higher mail quota, you can use SendGrid to send email. For any other quota increase, if you have Silver, Gold, or Platinum support package, you can contact your support representative to request higher throughput limits. Otherwise, you can submit a request for more quota in the Google Cloud Platform Console by selecting the particular quota and then click Edit Quotas.
Quotas for the App Engine flexible environment
When you deploy an application to the App Engine flexible environment, some Google Cloud Platform resources are consumed. You might not be able to modify these resources, however, these resources count against your quota.
Resources
An application may use the following resources, subject to quotas. Resources measured against billable limits are indicated with "(billable)." Resource amounts represent an allocation over a 24 hour period.
The cost of additional resources is listed on the Pricing page.
Default Google Cloud Storage bucket
Applications can use a Default Google Cloud Storage bucket, which has free quota and doesn't require billing to be enabled for the app. You create this free default bucket in the Google Cloud Platform Console App Engine settings page for your project.
The following quotas apply specifically to use of the default bucket. See pricing for Google Cloud Storage Multi-Regional buckets for a description of these quotas.
- Default Google Cloud Storage bucket stored data, I/O, and egress
-
There are limits to the total amount of data that may be stored in the
Default Google Cloud Storage bucket on a free basis.
New Pricing for Cloud Storage Operations and Network Egress Changes Starting in December, 2016. In December 2016, we will begin charging for operations on the Default Google Cloud Storage bucket. There will be a free quota for daily usage as shown below. For more detailed definitions and pricing information, see Google Cloud Storage pricing. In addition, network egress from the Default bucket will count against the 1GB daily Outgoing Bandwidth quota.
| Resource | Free default limit | Billing enabled default limit |
|---|---|---|
| Default Google Cloud Storage Bucket Stored Data | 5 GB | First 5 GB free; no maximum |
| Default Google Cloud Storage Bucket Class A Operations | 20,000 ops/day | First 20,000 ops/day free; no maximum |
| Default Google Cloud Storage Bucket Class B Operations | 50,000 ops/day | First 50,000 ops/day free; no maximum |
| Default Google Cloud Storage Bucket Network Egress | Up to the Outgoing Bandwidth quota | Up to the Outgoing Bandwidth quota free; no maximum |
Blobstore
The following quotas apply specifically to use of the blobstore.
- Blobstore stored data
- The total amount of data stored in the blobstore. Available for both paid and free apps.
| Resource | Free default limit | Billing enabled default limit |
|---|---|---|
| Blobstore Stored Data | 5 GB | First 5 GB free; no maximum |
Code and static data storage
- Static data limit
- In all languages except Go, no single static data file can be larger than 32MB. The limit for Go is 64MB.
- Total storage
- The storage quota applies to the total amount of code and static data stored by all versions of your app. The total stored size of code and static files is listed in the Main Dashboard table. Individual sizes are displayed on the Versions and Backends screens respectively. Free apps may only upload up to 1 GB of code and static data. Paid apps may upload more, but will be charged $ 0.026 per GB per month for any code and static data storage that exceeds 1 GB.
| Resource | Cost |
|---|---|
| Code & Static Data Storage - First 1 GB | Free |
| Code & Static Data Storage - Exceeding 1 GB |
Datastore
The Stored Data (billable) quota refers to all data stored for the application in Datastore and Blobstore. Other quotas in the "Datastore" section of the Quota Details screen in the Google Cloud Platform Console refer specifically to the Datastore service.
- Stored data (billable)
-
The total amount of data stored in datastore entities and corresponding indexes and the Blobstore.
It's important to note that data stored in the datastore may incur significant overhead. This overhead depends on the number and types of associated properties, and includes space used by built-in and custom indexes. Each entity stored in the datastore requires the following metadata:
- The entity key, including the kind, the ID or key name, and the keys of the entity's ancestors.
- The name and value of each property. Since the datastore is schemaless, the name of each property must be stored with the property value for any given entity.
- Any built-in and custom index rows that refer to this entity. Each row contains the entity kind, any number of property values depending on the index definition, and the entity key.
See How Entities and Indexes are Stored for a complete breakdown of the metadata required to store entities and indexes at the Bigtable level.
- Number of indexes
- The number of Datastore indexes that exist for the application. This includes indexes that were created in the past and no longer appear in the application's configuration but have not been deleted. See the Datastore limits page for additional details about limits.
- Write operations
- The total number of Datastore write operations.
- Read operations
- The total number of Datastore read operations.
- Small operations
- The total number of Datastore small operations. Small operations include calls to allocate Datastore IDs or keys-only queries.
| Resource | Free default daily limit | Billing enabled default limit |
|---|---|---|
| Stored Data (billable) | 1 GB * | 1 GB free; no maximum.
Beyond free quota, billing rates apply. |
| Number of Indexes | 200 * | 200 |
| Entity Reads | 50,000 | 50,000 free; no maximum.
Beyond free quota, billing rates apply. |
| Entity Writes | 20,000 | 20,000 free; no maximum.
Beyond free quota, billing rates apply. |
| Entity Deletes | 20,000 | 20,000 free; no maximum.
Beyond free quota, billing rates apply. |
| Small Operations | 50,000 | Unlimited |
*Not a daily limit but a total limit. Auto-generated single property ascending indexes are not counted towards this limit.
Note: Datastore operations generated by the Datastore Admin and Datastore Viewer count against your application quota.
Deployments
- Deployments
- The number of times the application has been uploaded by a developer. The current quota is 10,000 per day.
An application is limited to 10,000 uploaded files per version. Each file is limited to a maximum size of 32 megabytes. Additionally, if the total size of all files for all versions exceeds the initial free 1 gigabyte, then there will be a $ 0.026 per GB per month charge.
Instance hours
Instance usage is billed by instance uptime, at a given hourly rate. Billable time starts when an instance starts, and ends fifteen minutes after it shuts down. There is no billing for idle instances above the maximum number of idle instances set in the Performance Settings tab of the GCP Console.
There are separate free daily quotas for frontend and backend instances. Note that when you use App Engine Services, the service's instance class determines which quota applies.
| Resource or API Call | Free Quota |
|---|---|
| Frontend Instances (Automatic Scaling Modules) | 28 free F1 instance-hours per day |
| Backend Instances (Basic and Manual Scaling Modules) | 9 free B1 instance-hours per day |
Logs
The Logs API is metered when log data is retrieved, and is available for both paid and free apps.
The logs ingestion allotment refers to request logs and application logs data for an application, and is available for both paid and free apps. Logging for App Engine apps is provided by Stackdriver. See Stackdriver pricing for more information on rates and limits.
App Engine bills for email use "by message," counting each email to each recipient. For example, sending one email to ten recipients counts as 10 messages.
- Messages sent
- The total number of messages that have been sent by the application. Note that the maximum quota for messages sent stays at free levels until the first charge for your application has cleared.
- Admins Messages Sent
- The total number of messages to application admins that have been sent by the application. (The total size limit for each admin email, including headers, attachments, and body, is 16KB).
- Message body data sent
- The amount of data sent in the body of email messages. This also counts toward the Outgoing Bandwidth quota.
- Attachments sent
- The total number of attachments sent with email messages.
- Attachment data sent
- The amount of data sent as attachments to email messages. This also counts toward the Outgoing Bandwidth quota.
| Resource | Free default daily limit | Billing enabled default daily limit | Maximum rate for all apps |
|---|---|---|---|
| Recipients emailed | 10 messages | 100 messages | 8 messages/minute |
| Admins emailed | 5,000 mails | 5,000 mails | 24 mails/minute |
| Message body data sent | 60 MB | 60 MB | 340 KB/minute |
| Attachments sent | 2,000 attachments | 2,000 attachments | 8 attachments/minute |
| Attachment data sent | 100 MB | 100 MB | 10 MB/minute |
You can add up to a maximum of 50 authorized senders for the Mail API.
Sending mail above your daily mail quota
If your app needs higher quotas for sending mail, you can use a third-party mail provider,such as SendGrid, Mailjet, or Mailgun, which have higher quotas.
Requests
- Outgoing bandwidth (billable)
-
The amount of data sent by the application in response to requests.
This includes:
- data served in response to both secure requests and non-secure requests by application servers, static file servers, or the Blobstore
- data sent in email messages
- data in outgoing HTTP requests sent by the URL fetch service.
- Incoming bandwidth
-
The amount of data received by the application from requests. Each incoming HTTP request can be no larger than 32MB.
This includes:
- data received by the application in secure requests and non-secure requests
- uploads to the Blobstore
- data received in response to HTTP requests by the URL fetch service
- Secure outgoing bandwidth
- The amount of data sent by the application over a secure connection in response to requests. Secure outgoing bandwidth also counts toward the Outgoing Bandwidth quota.
- Secure incoming bandwidth
- The amount of data received by the application over a secure connection from requests. Secure incoming bandwidth also counts toward the Incoming Bandwidth quota.
| Resource | Free default limit | Billing enabled default limit | ||
|---|---|---|---|---|
| Daily limit | Maximum rate | Daily limit | Maximum rate | |
| Outgoing bandwidth (billable, includes HTTPS) | 1 GB | 56 MB/minute | 1 GB free; 14,400 GB maximum | 10 GB/minute |
| Incoming bandwidth (includes HTTPS) | 1 GB; 14,400 GB maximum | 56 MB/minute | None | None |
Search
Free quotas for Search are listed in the table below. Refer to the Java, Python, and Go documentation for a detailed description of each type of Search call.
Once billing is turned on, Search API resources are charged according to the rates on the pricing schedule.
| Resource or API call | Free Quota |
|---|---|
| Total storage (documents and indexes) | 0.25 GB |
| Queries | 1000 queries per day |
| Adding documents to indexes | 0.01 GB per day |
The application console quota section displays a raw count of API requests. Note that when indexing multiple documents in a single call, the call count is increased by the number of documents.
The Search API imposes these limits to ensure the reliability of the service:
- 100 aggregated minutes of query execution time per minute, within an app and an index.
- 15,000 Documents added/deleted per minute
Note: Although these limits are enforced by the minute, the GCP Console displays the daily totals for each. Customers with Silver, Gold, or Platinum support can request higher throughput limits by contacting their support representative.
Sockets
- Daily data and per-minute (burst) data limits
- Applications using sockets are rate limited on a per minute and a per day basis. Per minute limits are set to handle burst behavior from applications.
| Resource | Per day limits | Per minute (burst) limits |
|---|---|---|
| Socket Bind Count | 3,456,000 | 19,200 |
| Socket Create Count | 3,456,000 | 19,200 |
| Socket Connect Count | 3,456,000 | 19,200 |
| Socket Send Count | 663,552,000 | 3,686,400 |
| Socket Receive Count | 663,552,000 | 3,686,400 |
| Socket Bytes Received | 3.3 TB | 2.4 GB |
| Socket Bytes Sent | 3.3 TB | 2.4 GB |
Task Queue
- Task Queue API calls
- The total number of times the application called the Task Queue API to enqueue a task.
- Task Queue stored task count
- The total number of tasks the application has enqueued that are not yet executed.
- Task Queue stored task bytes
- The bytes consumed by tasks the application has enqueued that are not yet executed.
When a task executes, its associated requests count toward the application request quotas
These limits apply to all task queues:
| Resource | Free default limit | Billing enabled default limit | ||
|---|---|---|---|---|
| Daily limit | Maximum rate | Daily limit | Maximum rate | |
| Task Queue API calls | 100,000 | n/a | 1,000,000,000 | n/a |
| Task Queue management calls (using the GCP Console) | 10,000 | n/a | 10,000 | n/a |
| Resource | Free default limit | Billing enabled default limit |
|---|---|---|
| Task Queue stored task count | 1,000,000 | 10,000,000,000 |
| Task Queue stored task bytes | 500 MB. Configurable up to 1 GB. | None. |
| Maximum number of queues (includes both push and pull queues but not the default queue) | 10 queues. | 100 queues. |
Note: Once a task has been executed or deleted, the storage it uses is freed. Your storage quota is updated at regular intervals and might not show the reclaimed space immediately. You can configure the Stored Task Bytes Limit by adjusting your queue configuration. See the Python, Java, or Go, or PHP documentation for more details.
The following limits apply to task queues according to their type:
| Push Queue Limits | |
|---|---|
| Maximum task size | 100KB |
| Queue execution rate | 500 task invocations per second per queue |
| Maximum countdown/ETA for a task | 30 days from the current date and time |
| Maximum number of tasks that can be added in a batch | 100 tasks |
| Maximum number of tasks that can be added in a transaction | 5 tasks |
| Default maximum number of task queues | 100 queues. Contact Support to request an increase. |
| Pull queue limits | |
|---|---|
| Maximum task size | 1MB |
| Maximum countdown/ETA for a task | 30 days from the current date and time |
| Maximum number of tasks that can be added in a batch | 100 tasks |
| Maximum number of tasks that can be added in a transaction | 5 tasks |
| Maximum number of tasks that you can lease in a single operation | 1000 tasks |
| Maximum payload size when leasing a batch of tasks | 32MB |
| Default maximum number of task queues | 100 queues. Contact Support to request an increase. |
Cron
The following quotas apply specifically to Cron jobs.
- Cron jobs
- Number of cron jobs. Available for both paid and free apps.
| Resource | Free default limit | Billing enabled default limit |
|---|---|---|
| Cron job | 20 cron jobs | 250 cron jobs |
URL Fetch
- URL Fetch API calls
- The total number of times the application accessed the URL fetch service to perform an HTTP or HTTPS request.
- URL Fetch data sent
- The amount of data sent to the URL fetch service in requests. This also counts toward the Outgoing Bandwidth quota.
- URL Fetch data received
- The amount of data received from the URL fetch service in responses. This also counts toward the Incoming Bandwidth quota.
| Resource | Free default limit | Billing enabled default limit | ||
|---|---|---|---|---|
| Daily limit | Maximum rate | Daily limit | Maximum rate | |
| UrlFetch API calls | 657,000 calls | 3,000 calls/minute | 860,000,000 calls | 660,000 calls/minute |
| UrlFetch data sent | 4 GB | 22 MB/minute | 4.5 TB | 3,600 MB/minute |
| UrlFetch data received | 4 GB | 22 MB/minute | 4.5 TB | 3,600 MB/minute |
