Diagnose: Quota exceeded for quota metric

TL;DR

Check for a runaway: did usage spike 100x at some timestamp? Fix by cause: - Legitimate need: request a quota increase from the quotas page. This is the only fix for real growth. - Runaway loop: fix the code first (backoff, batching, idempotency), then the quota error clears on its own as usage drops. - Wrong project/region: quotas are per project per region.

When to use

You are seeing this: Symptom: "Quota exceeded for quota metric '[METRIC]' and limit '[LIMIT]' of service '[SERVICE]'". Use this skill when you run into "Diagnose: Quota exceeded for quota metric".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Steps

1. Symptom: "Quota exceeded for quota metric '[METRIC]' and limit '[LIMIT]' of service '[SERVICE]'".
2. Cause: the project hit a quota: API rate, concurrent operations, or resource count. Either legitimate growth or a bug generating load.
3. Confirm:
4. Copy the exact metric name from the error.
5. Console: IAM and Quotas, filter by that metric. See current usage vs limit and which region/service.
6. Check for a runaway: did usage spike 100x at some timestamp? Look at your deploy/retry logs around that time. Agents' retry loops are a classic cause.
7. Fix by cause:

• Legitimate need: request a quota increase from the quotas page. Some increases are automatic, some need review. This is the only fix for real growth.
• Runaway loop: fix the code first (backoff, batching, idempotency), then the quota error clears on its own as usage drops.
• Wrong project/region: quotas are per project per region. You may just be deploying to a region with a low default limit; switch regions or raise that region's limit.

5. Do not hammer retries against a quota error. It extends the block and can look abusive. Back off, fix, then retry once.
6. Prevention: for batch workloads, add client-side rate limiting and concurrency caps before you need quota increases. Quotas protect the platform; your code should protect your quota.
7. Verify: the quotas dashboard shows usage under limit after the fix, then rerun the original operation.

Verified 2026-09-26: quota error format with named metric is documented across services (BigQuery quotaExceeded docs describe the pattern). The increase-request flow is the documented quotas-page process.