Hi,
We have been encountering a sudden increase in the following error from UrlFetchApp.fetch() calls inside Google Ads Scripts, starting within the last 48 hours, with no code changes on our end in the past week:
Bandwidth quota exceeded: [url]. Try reducing the rate of data transfer.
We reached out to Google Ads Scripts support, but as noted on the official support page (developers.google.com/google-ads/scripts/docs/support/get-help), UrlFetchApp is a Google Apps Script service and falls outside the scope of Ads Scripts support — so we’re bringing this here.
Why this doesn’t match the documented quotas
According to the official quotas page (developers.google.com/apps-script/guides/services/quotas, last updated 2026-04-20), the documented UrlFetchApp limits are:
| Limit | Value |
|---|---|
| Calls per day (consumer) | 20,000 |
| Calls per day (Workspace) | 100,000 |
| Response size per call | 50 MB max |
| POST size per call | 50 MB max |
There is no documented daily bandwidth cap. Our responses are well within the 50 MB per-call limit, and we do not believe we are near the daily call count ceiling for the affected accounts.
The Bandwidth quota exceeded error does not correspond to any listed quota. The phrase “rate of data transfer” in the error message suggests a throughput or rate-based throttle — but we cannot find this documented anywhere.
Questions
1. What quota does this error actually map to?
Is there a rate-based bandwidth throttle (bytes/second or bytes/minute) on UrlFetchApp that is not listed in the quotas documentation? If so, what is the limit and how is it scoped?
2. Is quota enforced per user (email) or per destination domain?
The documentation states quota is “per user.” However, if there is also a per-domain throttle on the destination being fetched, multiple scripts calling the same endpoint could exhaust a shared pool regardless of the user count. Can you confirm whether domain-level throttling exists for UrlFetchApp?
3. Are there undocumented short-window burst limits?
Separate from the daily call count, are there per-minute or per-hour bandwidth rate limits that are not surfaced in the quotas page?
4. Did quota enforcement recently change?
These scripts have been running at comparable usage levels for a long time. The error only began appearing at scale very recently — within the last 48 hours — with nothing changed on our side. The quotas page itself was last updated 2026-04-20. Was there a recent change to how bandwidth limits are enforced or calculated?
5. Does MCC-level parallel execution affect quota differently?
Some scripts run at the MCC level, executing in parallel across multiple child accounts (up to 50 at a time). Does each parallel child account execution count independently toward the quota of the MCC account’s email? Or does parallel execution introduce an additional concurrency-based constraint not covered in the docs?
Any clarity on the actual mechanics behind this error — particularly whether it is rate-based, domain-scoped, or subject to a recent enforcement change — would be very helpful.
Thank you.