mediumFoundationUSE#cloud run#memory#limit#oom#cpu

Cloud Run memory limit exceeded — 128 MiB default OOM

Cloud Run container OOMs and restarts under normal traffic

Likely source:availabilityperformance

Focused incident mode — strips away everything but this runbook.

Symptoms

  • Cloud Run container OOMs and restarts under normal traffic
  • gcloud run services describe shows memory request at default 128 MiB
  • Requests start failing with 500 / 'container exited' at peak
  • gcloud logging shows Out of memory or killed by signal 9

Cloud Run defaults to 128 MiB, which is tiny for most runtimes. Right-size memory by observing the utilization series, and remember CPU scales with memory — raise both together.

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Configured memory

    gcloud run services describe <SERVICE> --region <REGION> --format='value(spec.template.spec.containers[0].resources)'

  • OOM signal in logs

    gcloud logging read 'resource.type=cloud_run_revision AND "out of memory" AND resource.labels.service_name=<SERVICE>' --limit=20 --format=text

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • resources.memory is 128Mi
  • Usage peaks near the limit at moderate traffic
  • More requests/parallelism raises memory until OOM

Confirm before fixing

gcloud run services describe <SERVICE> --region <REGION> --format='value(spec.template.spec.containers[0].resources.memory)'
READ

Confirm the memory setting

Expected: 128Mi

Fix

gcloud run services update <SERVICE> --region <REGION> --memory <512Mi> --cpu <1>
CHANGE

Raise memory (and CPU to match) above observed peak

Expected: Updated [<SERVICE>].

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
gcloud run services describe <SERVICE> --region <REGION> --format='value(spec.template.spec.containers[0].resources.memory)'
READ

Confirm the current memory limit

2
gcloud monitoring time-series list --filter='metric.type="run.googleapis.com/container/memory/utilizations" AND resource.labels.service_name=<SERVICE>' --format=json
READ

Measure peak utilization

3
gcloud run services update <SERVICE> --region <REGION> --memory <NEW_LIMIT> --cpu <CPU>
CHANGE

Raise memory and CPU above peak

4
gcloud run services describe <SERVICE> --region <REGION> --format='value(status.conditions[?type==Ready].status)'
READ

Verify the service stays Ready after deploy

Prevention

  • Set memory/cpu explicitly on every service; never ship the default.
  • Use the memory utilization series to tune limits during a load test.
  • Enable CPU boost for cold-start-heavy services.
  • Set per-instance concurrency so per-request memory stays bounded.

Related runbooks

Same stack, same failure family — worth a skim.

OOMKilled containers — memory limit exceededcritical

Exit code 137 on the container

KubernetesFoundationUSE3 causes
Open runbook
Cloud Run revision not serving — 503 / startup failurehigh

gcloud run services describe shows latest revision in state not serving

Google CloudFoundationRED3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.