Quota exceeded for quota metric 'BigQuery API'" when the billing export job runs

TL;DR

Make the export job scan less data URIs filter on the partition date so it reads only recent days, and run it less often. If the job still needs the full scan, request a quota increase for the project that runs the query. Billing export tables grow forever, so an unfiltered full-table scan will always eventually blow the quota.

The error

Quota exceeded for quota metric 'BigQuery API'

Fix it

1. See which quota is exhausted: in the console go to IAM and Admin, then Quotas, and filter for BigQuery API in the project that runs the query. Expected: one metric (concurrent queries or query usage) sitting at 100 percent.

2. Rewrite the job query to touch only recent partitions, for example by filtering the invoice month or the last N days of the partitioned export table. Expected: the query validator reports far fewer bytes to be processed.

3. Cut the schedule frequency (daily instead of hourly) and let identical reruns hit the 24-hour query cache instead of rescanning. Expected: quota consumption drops on the Quotas page within the hour.

4. If the workload genuinely needs the scan, request a quota increase from the same Quotas page. Expected: approval raises the limit; the job then completes without the quota error.

Use this when

• A billing-export analysis job that used to work starts failing with quota errors
• The job scans 12 to 18 months of export history on every run
• Several agents or dashboards query the same export tables at once

Not for this skill when

• The error is table-not-found on the export (fix the table name first)
• The quota error names a different API, like the Cloud Billing API (different quota, different fix)
• The job fails on permissions rather than quota

Variant phrasings

• BigQuery billing export job hits quota limit
• too many BigQuery queries from cost reporting job
• BigQuery API quota exceeded on scheduled query
• reduce BigQuery bytes scanned on billing export

Why it happens

Quota applies to the project running the query, not to the billing data itself. Export tables are partitioned by day and grow without bound, so a query with no partition filter scans the entire history every run. As history grows, the same query costs more quota each time until it tips over.

Edge cases

• Concurrent-query quota and bytes-scanned quota are separate limits; fix the one that is actually exhausted
• Writing the job's output to a summary table once, then querying the summary, beats rescanning raw export every time
• Cached query results are free for 24 hours, so rerunning the identical query does not cost quota twice
• Quota increases take time to approve; the partition filter is the immediate fix

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qrK-elcSGOLIBbIaPiRctg