Quotas
Una aplicación GAE puede consumir recursos hasta los limites que marcan las cuotas. Con estas cuotas , App Engine te asegura que tu aplicación no excederá tu presupuesta, y además que las otras aplicaciones que se estén ejecutando en App Engine no impactarán sobre el rendimiento de tu aplicación , ni la tuya impactará sobre la de otros.
Contents
- Safety Limits and Billable Resources
- How Resources are Replenished
- When a Resource is Depleted
- Resources
Límites de seguridad y límites de recursos facturables
Las cuotas de seguridad son configuradas por Google para proteger la integridad del sistema App Engine.Estas cuotas aseguran que ninguna app puede hacer abuso de consumo de recursos en detrimento de otras apps. Los recursos facturables son configurados por el administrados de la app en la pestaña Billing Settings de la consola de administración. Estas cuotas permiten a los administradores gestionar el rendimiento de la app y su coste.
Cuotas de seguridad
Las cuotas de seguridad incluyen cuotas diarias y cuotas por-minuto
- Las cuotas diarias son actualizadas diariamente en la medianoche (Pacific time). Las apps de pago pueden exceder esta cuota gratuita hasta que su presupuesta se agote.
- Las cuotas por-minuto protegen a la app de consumir todos sus recursos en periodos muy cortos de tiempo, y prevenir a otras apps de monopolizar un recurso en concreto. Si tu app consume un recurso demasiado rápidamente y supera una de las cuotas por-minuto, entonces aparecerá “Limited” al lado de la cuota que se supera en la pantalla Quota Details en la Admin Console. Peticiones de recursos que tienen superado el máximo por minuto serán denegadas. Ver When a Resource is Depleted para más detalles.
Las aplicaciones de pago tiene cuotas diarias y por-minuto más altas que las aplicaciones gratuitas. Cuando una aplicación de pago excede esta cuota, puede continuar utilizando el recurso hasta que se agote su presupuesto. Puedes consultar todas las cuotas que hay en la sección Resources .These quotas are strictly for safety and represent an extreme that most applications will not encounter in normal usage.
Truco:En aplicaciones de pago, en las cuotas el máximo por minuto están preparados para altos niveles de tráfico, suficientes para aguantar picos de tráfico. Si crees que una cuota en particular no se ajusta a tus necesidades, accede a create a feature request issue in the issue tracker. Nota: Ten en cuenta que archivar una solicitud de este tipo no te asegurará que la cuota se incremente para una app en particular, pero nos ayudará a entender porqué esta cuota es potencialmente baja para casos generales de uso.
Si en tu app vas a tener altos niveles de tráfico, o por alguna razón tu app requiere altas cuotas (por ejemplo cuando se lanza el producto o en tests de carga), se puede contratar una premier account es la opción más apropiada.
Billable Resource Quotas
Every application gets an amount of each billable resource for free, but application administrators can increase the billable quotas by enabling paid apps and setting a daily budget. You will be charged for the resources your application actually uses, and for the amount of resources used above the free quota thresholds. Paid applications incur a minimum spend of $2.10/week.
After you enable billing for your application, you can set your daily budget and adjust quotas using the Administration Console. For more information about setting your budget and allocating resources, see Billing. When you enable billing for your application, the application’s safety quotas increase. See the Resources section for details.
How Resources are Replenished
App Engine tracks your application’s resource usage against system quotas. For both free and paid applications, 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 budget 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 Forbidden status code for the request instead of calling a request handler. The following resources have this behavior:
- Bandwidth, incoming and outgoing
Tip: You can configure your application to serve a custom error page when your application exceeds a quota. For details, see Custom Error Responses documentation forPython and Java.
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 Java API, this exception is com.google.apphosting.api.ApiProxy.OverQuotaException.
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.')
If you’re exceeding your system resource quota unexpectedly, consider profiling your application’s performance.
Is your app exceeding the default limits? If you are a Premier customer, you can request additional quota by contacting support. If you are not a Premier customer, you canapply for more Mail API quota or file a feature request for any other quota increase. Or you can find out more about our Premier accounts.
Resources
An application may use the following resources, subject to quotas. Resources measured against billable resources are indicated with “(billable).” Resource amounts represent an allocation over a 24 hour period.
The cost of additional billable resources is listed on the Billing page.
Blobstore
Data stored in the blobstore counts toward the Stored Data (billable) quota, described above. The following quotas apply specifically to use of the blobstore.
- Blobstore Stored Data
- The total amount of data stored in the blobstore. Also counts toward the Stored Data (billable) quota. Available for both paid and free apps.
| Resource | Free Default Limit | Billing Enabled Default Limit |
|---|---|---|
| Blobstore Stored Data | 5 GB | 5 GB free; no maximum |
Channel
- Channel API Calls
- The total number of times the application accessed the Channel service.
- Channels Created
- The number of channels created by the application.
- Channel Hours Requested
- The number of hours of channel connect time requested by the application.
- Channel Data Sent
- The amount of data sent over the Channel service. This also counts toward the Outgoing Bandwidth quota.
| Resource | Free Default Limit | Billing Enabled Default Limit | ||
|---|---|---|---|---|
| Daily Limit | Maximum Rate | Daily Limit | Maximum Rate | |
| Channel API Calls | 657,000 calls | 3,000 calls/minute | 91,995,495 calls | 32,000 calls/minute |
| Channels Created | 100 channels | 6 creations/minute | Based on your budget | 60 creations/minute |
| Channels Hours Requested | 200 hours | 12 hours requested/minute | Based on your budget | 120 hours requested/minute |
| Channel Data Sent | Up to the Outgoing Bandwidth quota | 22 MB/minute | 2 GB | 740 MB/minute |
Code and Static Data Storage
- Code and Static Data
- Storage space used by all program code and static data. This combines space used by all versions. For example, if you keep two versions of your application, each using 100Mb, this is 200Mb. 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.13 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 | $0.13 per GB per month |
Datastore
The Stored Data (billable) quota refers to data stored for the application in the (deprecated) Master/Slave Datastore, the Task Queue, and the Blobstore. The High Replication Storage (billable) quota refers to data stored for the application in the (now standard) High Replication Datstore. Other quotas in the “Datastore” section of the Quota Detailsscreen in the Administration Console refer specifically to the Datastore service.
- Stored Data (billable)
- The total amount of data stored in datastore entities and corresponding indexes, in the task queue, and in 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 and How Index Building Works for a detailed explanation of how datastore indexes are managed.
- 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 using AppCfg’s
vacuum_indexescommand. - 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.
| Resource | Free Default Daily Limit | Billing Enabled Default Limit |
|---|---|---|
| Stored Data (billable) | 1 GB Note: Not a daily limit but a total limit. | 1 GB free; no maximum |
| Number of Indexes | 200 Note: Not a daily limit but a total limit. | 200 |
| Write Operations | 50,000 | Unlimited |
| Read Operations | 50,000 | Unlimited |
| Small Operations | 50,000 | Unlimited |
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, the total size of all files for all versions can not exceed 1 gigabyte.
Logs
The Logs API is metered when log data is retrieved, and is available for both paid and free apps.
Logs storage contains request logs and application logs for an application, and is available for both paid and free apps. For paid apps, you can increase total logs storage size and/or log data retention time, using the Log Retention setting in the Admin Console.
| Resource | Free Default Limit | Billing Enabled Default Limit |
|---|---|---|
| Logs data retrieval | 100 megabytes | No maximum for paid app. |
| Logs data | 1 gigabyte | Log data kept for a maximum of 365 days if paid, 90 days if free. |
App Engine bills for email use “by message,” meaning an email/recipient pair. In other words, a message is an instance of an email that is unique to a single recipient. For example, sending one email to ten recipients generates ten messages.
- Mail API Calls
- The total number of times the application accessed the mail service to send a message.
- Messages Sent (billable)
- The total number of messages (email/recipient pairs) 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.
- Admin Emails
- The total number of messages to application admins that have been sent by the application.
- 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 Limit | Billing Enabled Default Limit | ||
|---|---|---|---|---|
| Daily Limit | Maximum Rate | Daily Limit | Maximum Rate | |
| Mail API Calls | 100 calls | 32 calls/minute | 1,700,000 calls | 4,900 calls/minute |
| Messages Sent (billable) | 100 messages | 8 messages/minute | 100 messages daily until first charge cleared; 20,000 messages per day thereafter1. | 5,100 messages/minute |
| Admins Emailed | 5,000 mails | 24 mails/minute | 3,000,000 mails | 9,700 mails/minute |
| Message Body Data Sent | 60 MB | 340 KB/minute | 29 GB | 84 MB/minute |
| Attachments Sent | 2,000 attachments | 8 attachments/minute | 2,900,000 attachments | 8,100 attachments/minute |
| Attachment Data Sent | 100 MB | 10 MB/minute | 100 GB | 300 MB/minute |
1 The new limit of 20,000 messages per day only applies to applications created on or after December 14th, 2012. Applications created before this date will not be subject to this limit, even if they enable billing after December 14th.
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 sent over XMPP or the Channel API
- 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
- Instance Hours (billable)
- In general, instance usage is billed on an hourly basis based on the instance’s uptime. Billing begins when the instance starts and ends fifteen minutes after the instance shuts down. You will be billed only for idle instances up to the number of maximum idle instances set in the Performance Settings tab of the Admin Console. Runtime overhead is counted against the instance memory.
- 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 |
Task Queue
- Task Queue API Calls
- The total number of times the application accessed the task queue service 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. This quota is counted as part of Stored Data (billable).
Tip: You can configure the Stored Task Bytes Limit by adjusting your queue configuration. See the Python or Java documentation for more details.
| 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 |
| 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 MB. Configurable up to 1 GB. | None MB. Configurable up to Stored Data (billable). |
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 | 46,000,000 calls | 32,000 calls/minute |
| UrlFetch Data Sent | up to the Outgoing Bandwidth quota | 22 MB/minute | up to the Outgoing Bandwidth quota | 740 MB/minute |
| UrlFetch Data Received | up to the Incoming Bandwidth quota | 22 MB/minute | up to the Incoming Bandwidth quota | 740 MB/minute |
XMPP
- XMPP API Calls
- The total number of times the application accessed the XMPP service.
- XMPP Data Sent
- The amount of data sent via the XMPP service. This also counts toward the Outgoing Bandwidth quota.
- Recipients Messaged
- The total number of recipients to whom the application has sent XMPP messages.
- Invitations Sent
- The total number of chat invitations sent by the application.
- Stanzas Sent
- XMPP stanzas sent when the application sends a message, invitation, or presence information.
| Resource | Free Default Limit | Billing Enabled Default Limit | ||
|---|---|---|---|---|
| Daily Limit | Maximum Rate | Daily Limit | Maximum Rate | |
| XMPP API Calls | 46,000,000 calls | 257,280 calls/minute | 46,000,000 calls | 257,280 calls/minute |
| XMPP Data Sent | 1 GB | 5.81 GB/minute | 1,046 GB | 5.81 GB/minute |
| XMPP Recipients Messaged | 46,000,000 recipients | 257,280 recipients/minute | 46,000,000 recipients | 257,280 recipients/minute |
| XMPP Invitations Sent | 100,000 invitations | 2,000 invitations/minute | 100,000 invitations | 2,000 invitations/minute |
| XMPP Stanzas Sent | 10,000 stanzas | n/a | Based on your budget | n/a |
Paid Apps: Budgeting, Billing, and Buying Resources
Each App Engine application can consume a fixed amount of computing resources for free, defined by a set of quotas. If your application needs more resources you can make it a paid app by enabling billing and linking to a credit card or bank account for automatic payment. When your application uses resources beyond the free quotas, you will be charged only for the additional usage up to a daily maximum amount which you specify. Paid apps incur a minimum spend of $2.10 per week regardless of resource use. Charges are accumulated monthly and paid at the beginning of the following month.
Note: This page describes the monthly paid app billing system that is linked to a credit card or bank account. Prior to App Engine version 1.7.6 paid apps were billed on a weekly cycle. Some customers are still migrating from the older system. You can tell if your application is still running with weekly billing by looking at the Billing section in theApp Engine administration console. If the first billing item is named Billing Settings the app is still using the weekly billing system. If the item is Billing Status the app is using the monthly billing system.
Estimating Costs
When you enable billing, you must declare a maximum daily budget. When an application exceeds its daily budget, any operation whose free quota has been exhausted will fail.
Resource Billing Rates
Before you enable billing you should think about your application’s usage patterns and determine the maximum amount of money you’re willing to spend to keep your app running. When estimating resource use you should account for spikes in demand, so that a temporary increase in traffic will not shut down your app. The following table shows how resources are billed:
| Resource | Unit | Unit cost |
|---|---|---|
| Outgoing Bandwidth | Gigabytes | $0.12 |
Frontend Instances (F1 class) |
Instance hours | $0.08 |
Frontend Instances (F2 class) |
Instance hours | $0.16 |
Frontend Instances (F4 class) |
Instance hours | $0.32 |
Frontend Instances (F4_1G class) |
Instance hours | $0.48 |
| Discounted Instances | Instance hours | $0.05 |
Backend Instances (B1 class) |
Hourly per instance | $0.08 |
Backend Instances (B2 class) |
Hourly per instance | $0.16 |
Backend Instances (B4 class) |
Hourly per instance | $0.32 |
Backend Instances (B4_1G class) |
Hourly per instance | $0.48 |
Backend Instances (B8 class) |
Hourly per instance | $0.64 |
| Stored Data (Blobstore) | Gigabytes per month | $0.13 |
| Stored Data (Datastore) | Gigabytes per month | $0.24 |
| Stored Data (Logs Data) | Gigabytes per month | $0.24 |
| Stored Data (Task Queue) | Gigabytes per month | $0.24 |
| Channel | Channel opened | $0.0001 ($0.01/100 channels) |
| Recipients Emailed | $0.0001 | |
| XMPP | XMPP stanzas | $0.000001 ($0.10/100,000 stanzas) |
| Logs API | Gigabytes | $0.12 |
| SNI SSL certificates | Sets of five SNI certificate slots per month | $9.00 |
| SSL Virtual IPs (VIPs) | Virtual IP per month | $39.00 |
| PageSpeed bandwidth | Gigabytes (in addition to outgoing bandwidth charges) | $0.39 |
Note: Instead of being charged the standard hourly rates for instance use, you can purchase a fixed amount of instance hours per week at a discounted rate. You are billed for these hours whether or not they are actually used. If you do not use all the discounted hours in a week, the charge for the unused portion is added to the last day of the weeklybilling cycle.
Costs for Datastore Calls
Calls to the datastore API result in low-level billable operations. This table shows how calls map to datastore operations:
| API Call | Datastore Operations |
|---|---|
| Entity Get (per entity) | 1 read |
| New Entity Put (per entity, regardless of entity size) | 2 writes + 2 writes per indexed property value + 1 write per composite index value |
| Existing Entity Put (per entity) | 1 write + 4 writes per modified indexed property value + 2 writes per modified composite index value |
| Entity Delete (per entity) | 2 writes + 2 writes per indexed property value + 1 write per composite index value |
| Query | 1 read + 1 read per entity retrieved |
| Query (projection) | 1 read + 1 small per projected entity retrieved |
| Query (keys only) | 1 read + 1 small per key retrieved |
| Key allocation (per key) | 1 small |
The datastore operations are billed as follows:
| Operation | Cost |
|---|---|
| Write | $0.10 per 100k operations |
| Read | $0.07 per 100k operations |
| Small | $0.01 per 100k operations |
Note: Queries that specify an offset are charged for the number of results that are skipped in addition to those that are returned.
Billing Cycles
When you enable billing you specify a maximum daily budget. This is the maximum resource cost you are willing to pay. This daily budget will limit the total amount you can be charged on any single day. The daily budget should be large enough to be able to handle spikes in resource usage. An application can only consume billable resources up to its maximum daily budget. When an application exceeds its daily budget, any operation whose free quota has been exhausted will fail. Charges are posted in daily, weekly, and monthly billing cycles:
- Daily: Every day you are charged for the resources you actually use. Usage up to the free quota limits is included in the usage total, but not in the billable amount. Usage above the free quota is charged at the appropriate rate. In particular, if your budget includes weekly discounted instance hours, instance use is billed at the discounted rate until you consume the allocated amount. Additional usage is billed at the regular rates.
- Weekly: The weekly billing cycle begins on the day that you enable billing. At the end of each weekly billing cycle, the seventh day, additional daily charges can appear: If there are unused discount instance hours a charge for the unused hours is added. If the resource bill for the week is below the minimum spend of $2.10 per week, the shortfall is added. Note that the weekly cycles can span a month, so these end of week “make-up” charges appear on the monthly bill that contains the last day of the weekly billing cycle.
- Monthly: At the beginning of each month all daily charges for the previous month are summed, applicable taxes are computed, and the total charges are debited from the payment instrument that is linked to the app.
Taxes
Some countries tax App Engine fees. If taxes apply in your country of residence, your bill will include any applicable taxes. Taxes appear only in the Transaction History log. You do not need to include taxes in your daily budget. They are added to your charges after daily spend has been calculated, so the final charge to your account, including taxes, may be larger than the daily budget amount.
Creating a Paid App
Follow these steps to start creating a paid app:
- Sign in to the Administration Console at https://appengine.google.com. Google Apps users can sign in at https://appengine.google.com/a/your_domain.com.
- Select an application.
- Click the Billing Status link (under the Billing section) in the menu on the left side.
The billing status page appears and the application’s status will be Free.
Billing Administrators
Only billing administrators can enable billing and manage paid apps. To be a billing administrator a user must already be one of the application’s application administrators. A paid app should have more than one billing administrator to ensure there is always someone available who can change the budget. Before you assign billing administrators be sure you have granted an application administrator role to all the people you have in mind.
The application administrator who initially enables billing automatically becomes a billing administrator. The initial administrator can be removed later once other billing administrators exist. To add or remove billing administrators click Manage Billing Administrators. A list of all the current application administrators will appear, with check boxes next to each. Check and uncheck the boxes to add or remove billing administrators. Then click Save.
Enable Billing
Click Enable Billing. The first time you enable billing, three consecutive screens appear to enter budget, business contact, and payment information:
- Budget: Specify your application’s budget. There are two fields:
- Maximum Daily Budget: This is the maximum dollar amount of billable resources you’re willing to purchase each day. See Estimating Costs.
- Weekly Discounted Instance Hours: You can purchase a fixed amount of weekly instance hours at a discounted rate. You are billed for these hours whether or not they are actually used.
- Billing profile: Enter your company’s address and one or more billing contacts with phone, email, and notification preferences. The person who initially enables billing automatically becomes the primary contact. Contacts do not have to be billing administrators. Currently the only billing notifications contacts can receive is a warning when a charge has failed. Each new contact receives an email that includes a link that must be clicked to verify the address and to enable the transmission of notifications.
- Billing settings: Enter information for one or more credit cards or bank accounts. You must have at least one account which will be the primary payment source for the monthly bills. If you enter other accounts one of them can be selected as a backup. If a charge to the primary fails, the billing system will try the backup account.
Note: Currently, the billing system only accepts US bank accounts.After you fill in all three screens click Submit. You’re done! If you cancel out of enable billing while creating a paid app none of the budget, profile, or settings information will be retained. You’ll have to enter it all again.
Verify Paid App Status
When you click Submit the application’s billing status changes from Free to Enabling Billing. It can remain in this state for several minutes while Google processes your billing settings. You can cancel the pending enable process by pressing Do not enable billing.
Note that the status page does not update automatically. To verify that your application has become a paid app refresh the billing status page until you see that the status has changed to Enabled. After the app has been enabled it may take several minutes for any changes in budget quotas to take effect.
Managing a Paid App
Once billing is enabled all of the application’s billing administrators can use the links in the application console billing section to view and change billing information. The following table shows what management operations are available from each page:
| Billing Page | Operations |
|---|---|
| Billing Status | View billing status, Change budget, Add/remove/view billing administrators |
| Usage History | View daily usage statistics and costs |
| Transaction History (*) | Make payments, view the current balance and monthly billing transactions |
| Billing Profile (*) | View and change contact information |
| Billing Settings (*) | View and change payment information |
(*) These pages are only visible to billing administrators.
Billing Status
The app’s current billing status is displayed on the Billing Status page. Possible values are:
- Free
- Enabling Billing
- Enabled
- Grace Period
When a monthly payment fails the app’s account is delinquent and its status becomes “Grace Period.” The app will continue to run with its budget constraints and you have up to 30 days to pay the outstanding balance. More information can be found on the App Engine Billing FAQ page.
Making a Payment
The billing system calculates your monthly charges and posts them in the transaction history on the first of the month. The exact date that the linked payment account is actually debited may vary, so when the automatic withdrawal or charge appears in the transaction history it may be after the first of the month.
You can also make a payment through any of your linked accounts at any time by visiting the Transaction History billing page. At the top of the page you’ll see your current balance, and a Make a payment button.
Changing the Budget
You can change your budget any time during a billing cycle, but the budget can only be changed when the billing status is Enabled or Grace Period. Go to the Billing Statuspage and click Change Budget. Make your changes and click Submit. (A new budget can be specified when you re-enable a paid app that has had billing disabled.)
Changing the maximum daily budget can be tricky. When you increase the maximum daily budget the new limit takes effect immediately, so an application that has been failing because it is over budget will work again. However, if you lower the daily maximum the change will take effect immediately only if the current daily usage is below the old maximum. Otherwise, the new maximum takes effect the next day.
You cannot change the weekly discounted instance hours in the middle of the weekly billing cycle, since the accounting process has already begun. When you change the weekly discounted instance hours the change will apply at the start of the next weekly billing cycle.
Adding and Removing Billing Administrators
Any billing administrator can add or remove other billing administrators. Application administrators can only view the list of billing administrators. Go to the Billing Status page and click Manage Billing Administrators. A billing administrator can remove himself – as long as other billing administrators exist. There must be at least one billing administrator at all times.
Changing Contact Information
To change company contact information go to the Billing Profile page. You can edit or remove existing contacts or add new ones. You can also edit the company business information.
Changing Payment Settings
To change payment information go to the Billing Settings page. You can edit or remove existing payment accounts or add new ones.
Disabling Billing
When you disable billing your app’s usage limits will revert to the free quotas. You will still be charged for the minimum weekly spend for the current week, which includes any weekly discounted instance hours; the charge will appear on the next month’s bill. Go to the Billing Status page and click Disable Billing. When you disable billing your profile and settings are retained. When you re-enable billing these settings will still apply until you change them.
Note: Disabling an application does not automatically disable billing. If you disable your app but do not disable billing, the app can still be charged for fixed billing costs.
Billing Logs
The billing section includes two log pages:
Usage History
This page can be viewed by any application administrator. It shows daily resource usage reports along with details of any associated charges. Billing events, such as budget modifications and billed administrator changes also appear here. These reports can be viewed online, printed, or downloaded as a comma-separated values (CSV) file.
Frontend and backend instance hours are not enumerated by instance class name. They appear as a single instance hours total and the corresponding hourly usage and cost is computed as multiple of the base class (F1 and B1). For example, one hour of F4 usage is billed as four instance hours at the F1 rate.
Transaction History
This page can only be viewed by billing administrators. It shows all account activity related to resource charges and payments.
Note: Daily usage costs are rounded to the penny when they are displayed in the usage history, but the transaction history accumulates the actual full costs. Therefore the sum of the daily charges may not be identical to the amount reported (and billed) in the transaction history. Daily usage is posted on the next day but it can take longer to update the transaction history, so the transaction history may not include the most recent usage history.
Help
More information can be found on the App Engine Billing FAQ page. You can also report a billing problem to cloud services by filling out this online form.