Diagnose: Quota exceeded for quota metric

Symptom: "Quota exceeded for quota metric '[METRIC]' and limit '[LIMIT]' of service '[SERVICE]'".

Cause: the project hit a quota: API rate, concurrent operations, or resource count. Either legitimate growth or a bug generating load.

Confirm:

1. Copy the exact metric name from the error.
2. Console: IAM and Quotas, filter by that metric. See current usage vs limit and which region/service.
3. 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.

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.

Do not hammer retries against a quota error. It extends the block and can look abusive. Back off, fix, then retry once.

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.

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.