Instances are the computing units that App Engine uses to automaticallyscale yourapplication.At any given time, your application can be running on one instance or manyinstances, with requests being spread across all of them.

Your instances with manual scaling should run indefinitely, butthere is no uptime guarantee as instances can get early termination due to failures or restart for the updates. Hardware or software failures that cause earlytermination or frequent restarts can occur without warning and can takeconsiderable time to resolve.

All flexible instances may be restarted on a weekly basisif there are updates available. This schedule is not guaranteed.During restarts,critical, backwards-compatible updates are automatically rolled out to theunderlying operating system. Your application's image will remain the sameacross restarts.

Health checking

App Engine sends periodic health check requests to confirm that an instanceis running, and to check that an instance is fullystarted and ready to accept incoming requests. By default, these health checksare enabled and are known assplit health checks. An instance that receivesa health check must answer the health check within a specified time interval.

If you need to extend the default behavior of split health checks to yourapplication, you can customize theapp.yaml file to configure two types of health checks:

• Liveness checks detect that a VM instance and its container arerunning. When a VM instance fails the liveness check, the instance isrestarted automatically. Liveness checks can fail due to the configuredthresholds and time intervals, or due to the container crashing.
• Readiness checks detect that a VM instance is ready to accept incomingrequests. If a VM instance fails the readiness check, it means that the VMinstance has not finished its startup and is not ready to receive requests.When the VM instance passes the readiness check and has completed itsstartup, it is added to the pool of available instances.

Learn more about split health check behaviors in theMigrating to Split Health Checks guide.

As the instance goes through these health checks, theApp Engine logs can indicate that theinstance is in any of the following states:

• Healthy. The instance received the health check requests and is processingthe requests. A healthy status indicates that the instance has more than820 MB of available disk space and should respond to a health check withan HTTP status code of200.
• Unhealthy. The instance refused the health check requests and failedto respond to a specified number of consecutive health check requests.App Engine continues to send health check requests andrestarts the instance if an unhealthy instance continues to fail to respondto a predetermined number of consecutive health checks.
• Lameduck. The instance is scheduled to be shut down or restarted.During shutdowns, the instance finishes up ongoing requests, and refuses newrequests. The app returns a503 code to indicate that the instance isunable to handle requests. Before an instance shuts down or restarts, theshutdown script has a limited time period to run, and cannot be configuredto be shorter or longer.
• App Lameduck. The instance is preparing to serve traffic. The appreturns a503 code to indicate that the instance is unable to handlerequests. When a VM instance has completed startup and is ready toserve traffic, the instance will become healthy and process requests. If aVM instance does not start up in time, the instance changes to unhealthyand gets removed.

Both lameduck and app lameduck behaviors are part of a normal process that theVM instance goes through.

Monitoring resource usage

The Instances page of theGoogle Cloud console provides visibility into how your instances are performing. You can see the memory and CPU usage of each instance, uptime, number of requests, and other statistics. You can also manually initiate the shutdown process for any instance.

NTP with App Engine flexible environment

The App Engine flexible environment has network time protocol (NTP) services which use Google NTPservers. However, the NTP services in the flexible environment is not editable.

Instance location

Instances are automatically located by geographical region according to theproject settings.

Instance scaling

While an application is running, incoming requests are routed to an existing ornew instance of the appropriate service/version. Each active version must haveat least one instance running, and the scaling type of a service/versioncontrols how additional instances are created.You specify the scaling type in your app'sapp.yaml.By default, your app uses automatic scaling, which means App Engine willmanage the number of idle instances.

Automatic scaling

Automatic scaling creates instances based on request rate, response latencies,and other application metrics. You can specify thresholds for each of thesemetrics, as well as a minimum number instances to keep running at all timesby configuring theautomatic_scaling element.

Manual scaling

Manual scaling specifies the number of instances that continuously runregardless of the load level. This allows tasks such as complex initializationsand applications that rely on the state of the memory over time.

Manage services

Depending on thescaling type of your instance, you can manageservices and versions in the Google Cloud console or Google Cloud CLI.

Stop a version

Each version in App Engine runs within one or more instances, dependingon how much traffic you configured it to handle.

Click the tab for instructions on using the tool of your choice:

  gcloud app versions stop --service=SERVICEVERSION

Delete a service

Each service can be configured to use different runtimes and to operate withdifferent performance settings. You can't delete the default service. Deleting aservice also deletes all of its accompanying versions in your project.

Click the tab for instructions on using the tool of your choice:

  gcloud app services deleteSERVICE