🚨 GCP Error: 'The request was aborted because there was no available instance' — Cause, Fix, and Troubleshooting Guide

Overview

Cloud Run returns this when it cannot serve a request because it has no instance available and cannot create one fast enough — usually because the service hit its maximum instances ceiling or is throttled by a scaling/quota limit:

The request was aborted because there was no available instance.

Additional troubleshooting documentation can be found at:
https://cloud.google.com/run/docs/troubleshooting#no-available-instance

In logs it appears with HTTP 429 (or 500) and textPayload: "The request was aborted because there was no available instance." Cloud Run chose to drop the request rather than queue it indefinitely.

Symptoms

• Intermittent 429/500 under load with no available instance in Cloud Run logs.
• Errors spike during traffic bursts, then clear when traffic subsides.
• Container concurrency is low while request volume is high.
• The service is pinned to a small --max-instances value.

Common Root Causes

1. Max instances ceiling reached

The service’s --max-instances is too low for peak traffic, so excess requests are aborted.

2. Slow cold starts + burst traffic

Instances take too long to start (heavy init, large image), so demand outruns supply during spikes.

3. Low per-instance concurrency

--concurrency=1 (or very low) means each instance serves one request, multiplying the instance count needed.

4. Container / CPU quota limits in the region

Project-level Cloud Run instance or CPU quota caps how many instances can exist.

How to Diagnose

All read-only.

# Current scaling config
gcloud run services describe api \
  --region=us-central1 --project=acme-prod-platform \
  --format="value(spec.template.metadata.annotations['autoscaling.knative.dev/maxScale'],
                  spec.template.spec.containerConcurrency)"

# Count the 'no available instance' aborts in logs
gcloud logging read \
  'resource.type="cloud_run_revision"
   AND textPayload:"no available instance"' \
  --project=acme-prod-platform --limit=20 \
  --format="value(timestamp)"

# Cold-start / startup latency signal
gcloud logging read \
  'resource.type="cloud_run_revision" AND httpRequest.status=429' \
  --project=acme-prod-platform --limit=10 \
  --format="table(timestamp, httpRequest.status, resource.labels.service_name)"

Correlate the abort timestamps with traffic peaks and the configured maxScale/concurrency.

Fixes

• Raise max instances to cover peak load:

gcloud run services update api \
  --region=us-central1 --project=acme-prod-platform \
  --max-instances=100

• Increase concurrency so each instance handles more requests (if the app is not CPU-bound per request):

gcloud run services update api \
  --region=us-central1 --project=acme-prod-platform \
  --concurrency=80

• Keep warm instances to absorb bursts and cut cold-start aborts:

gcloud run services update api \
  --region=us-central1 --project=acme-prod-platform \
  --min-instances=2

• Cut cold-start time: slim the image, defer heavy initialization, use startup CPU boost.
• Raise Cloud Run quota in the region if instance/CPU quota is the ceiling.

What to Watch Out For

• no available instance is a scaling limit, not an app crash — check max-instances/concurrency before debugging the container.
• Setting --concurrency=1 dramatically increases the instance count you need; raise it unless the app truly can’t be concurrent.
• --min-instances reduces cold-start aborts but incurs always-on cost — balance accordingly.
• If aborts persist even below max-instances, you may be hitting a regional Cloud Run/CPU quota — check and request an increase.

Related

• GCP Error: ‘Container failed to start’ (Cloud Run)
• GCP Error: ‘Memory limit exceeded’ (Cloud Run)
• GCP Error: ‘RESOURCE_EXHAUSTED: Quota exceeded’
• More in the GCP error guides.