Troubleshooting overview

This page provides general troubleshooting information for API Gateway.

Cannot run "gcloud api-gateway" commands

To run the gcloud api-gateway ... commands, you must have updated the Google Cloud CLI and enabled the necessary Google services. See Configuring your development environment for more.

Command "gcloud api-gateway api-configs create" says service account does not exist

If you run the gcloud api-gateway api-configs create ... command and receive an error in the form:

ERROR: (gcloud.api-gateway.api-configs.create) FAILED_PRECONDITION:
Service Account "projects/-/serviceAccounts/service_account_email" does not exist

Rerun the command but this time include the --backend-auth-service-account option to explicitly specify the email address of the service account to use:

gcloud api-gateway api-configs create CONFIG_ID \
  --api=API_ID --openapi-spec=API_DEFINITION \
  --project=PROJECT_ID --backend-auth-service-account=SERVICE_ACCOUNT_EMAIL

Ensure that you have already assigned the necessary permissions to the service account as described in Configuring your development environment.

Determining the source of API error responses

If requests to your deployed API result in an error (HTTP status codes 400 through 599), it may not be clear from the response itself if the error originates from the Gateway or from your backend. To determine this:

Go to the Logs Explorer page and select your project.

Go to Logs Explorer
Filter to the relevant gateway resource using the following Log query:
```
resource.type="apigateway.googleapis.com/Gateway"
resource.labels.gateway_id="GATEWAY_ID"
resource.labels.location="GCP_REGION"
```
Where:
- GATEWAY_ID specifies the name of the gateway.
- GCP_REGION is the Google Cloud region for the deployed gateway.
Find the log entry matching the HTTP error response you want to investigate. For example, filter by httpRequest.status.
Inspect the contents of the field jsonPayload.responseDetails.

If the value of the jsonPayload.responseDetails field is "via_upstream", then the error response originates from your backend and you will need to troubleshoot your backend directly. If it is any other value, then the error response originates from the Gateway; see the following sections of this document for further troubleshooting tips.

API request returns an HTTP 403 error

If a request to a deployed API returns an HTTP 403 error to the API client, it means the requested URL is valid but access is forbidden for some reason.

A deployed API has the permissions associated with roles granted to the service account that you used when you created the API config. Typically, the reason for the HTTP 403 error is that the service account does not have the necessary permissions to access the backend service.

If you defined the API and the backend service in the same Google Cloud Project, ensure that the service account has the Editor role assigned to it, or the role necessary to access the backend service. For example, if the backend service is implemented using Cloud Run functions, ensure that the service account has the Cloud Function Invoker role assigned to it.

API request returns an HTTP `401` or `500` error

If a request to a deployed API returns an HTTP 401 or 500 error to the API client, there may be a problem using the service account used when you created the API config to call your backend service.

A deployed API has the permissions associated with roles granted to the service account that you used when you created the API config. The service account is checked to make sure that it both exists, and can be used by the API gateway when the API is deployed.

If the service account is deleted or disabled after the gateway is deployed, the following sequence of events may occur:

Immediately after the service account is deleted or disabled, you may see 401 HTTP responses in your gateway logs. If the response_code_details field is set to "via_upstream" in the log entry'sjsonPayload, this indicates that deleting or disabling the service account is the cause of the error.
You may also see an HTTP 500 error without any corresponding log entry in the API gateway's logs. If there are no requests to your gateway immediately after the service account is deleted or disabled, you may not see the HTTP 401 responses, but the HTTP 500 errors without corresponding API gateway logs are an indication that the gateway's service account may no longer be active.

High latency API requests

Like Cloud Run and Cloud Run functions, API Gateway is subject to "cold start" latency. If your gateway has not received traffic for 15 to 20 minutes, requests made to your gateway within the first 10 to 15 seconds of the cold start will experience 3 to 5 seconds of latency.

If the issue persists after the initial "warm up" period, check the request logs of the backend service(s) you configured in your API Config. For example, if the backend service is implemented using Cloud Run functions, check the Cloud Logging entries of the associated Cloud Function request log.

Cannot view log information

If your API is responding correctly, but the logs contain no data, it typically means that you have not enabled all of the Google services required by API Gateway.

API Gateway requires that you enable the following Google services:

Name	Title
`apigateway.googleapis.com`	API Gateway API
`servicemanagement.googleapis.com`	Service Management API
`servicecontrol.googleapis.com`	Service Control API

To confirm that the required services are enabled:

gcloud services list

If you do not see the required services listed, enable them:

gcloud services enable apigateway.googleapis.com
gcloud services enable servicemanagement.googleapis.com
gcloud services enable servicecontrol.googleapis.com

For more information about the gcloud services, see gcloud services.