UrlFetchApp "Bandwidth quota exceeded" — error not matching documented quotas, sudden onset across many users

Google Workspace Developers Q&A
1

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.

2

I’m experiencing the exact same issue and I’m using a. very small data set

3

Same here! Is Google experiencing any techincal issue?

4

edit: The issue has been raised in Issues Tracker already: Google Issue Tracker

We’re also experiencing the same issue. Claude summarised our situation:

+1, confirming the same error in a different context.

Setup: Apps Script bound to a Google Sheet (not Google Ads Scripts), Workspace account, UrlFetchApp.fetchAll() calling the Gemini API (generativelanguage.googleapis.com). Same error string verbatim. Same onset around April 21, 2026. No code changes on my end.

Failure pattern doesn’t match a daily quota. I instrumented the script: per-call bandwidth is ~6 KB sent + ~1 KB received, well under any documented limit. On a fresh run, the first batch of 25 parallel calls fails with the bandwidth error, then succeeds on retry; subsequent batches sometimes succeed and sometimes fail with the same error. Failures correlate with bursts of parallel fetchAll, not cumulative bandwidth.

Worth flagging: Apps Script’s own release notes explicitly state the daily UrlFetch bandwidth quota was removed years ago (“The quota on total data received by UrlFetch per day per user has been removed.”), yet the error string references exactly that.

Additional questions on top of the original post:

  1. Is this a recently introduced or tightened concurrency/burst limit on UrlFetchApp.fetchAll()? Seeing it across both Google Ads Scripts and Apps-Script-bound-to-Sheets suggests it’s at the UrlFetchApp layer, not specific to either context.

  2. Is there a per-destination-domain throttle for calls into Google’s own APIs (*.googleapis.com)? Both setups here call Google-owned endpoints from Apps Script’s shared IP pool, which would explain why the throttle fires even when individual users are nowhere near per-user limits.

5

Facing the same issue from past few days. Tried with a new account. Worked fine for a few hours and started giving the same error.

6

Same here, with one extra data point that may help isolate the cause.

We run a Google Sheets sidebar add-on (Apps Script) that calls our own backend via UrlFetchApp.fetch. We started seeing Bandwidth quota exceeded at the same time you did — Apr 22-23 onset, no deploys on our side in the preceding two weeks (last prod deploy was Apr 12).

Pattern matching what you’ve described:

  1. Intermittent, not deterministic. Same call, same payload, same user — fails on attempt 1, succeeds on attempt 2 ~5s later. Backoff “works” but the underlying quota isn’t a per-day cap (recovery is way too fast for that). Behavior is consistent with a rolling bytes-per-window throttle: bytes accumulate, oldest bytes age out, window rolls forward.

  2. Both directions count. We see it on small-payload polling endpoints AND on heavier endpoints that return larger JSON. So it doesn’t appear to be purely response-size or purely call-rate — both contribute.

  3. Same destination domain shared across thousands of users. All our scripts hit *.ourdomain.com. If there’s a per-destination-domain throttle (your question #2), we should be seeing it disproportionately, and we are — top 5 user identities account for ~28% of our errors, suggesting the throttle attributes per effective user but the trigger threshold may be lower than expected.

  4. Localized error wording. We see it in EN, ES, IT, DE, PT — same underlying throw, locale-translated message. So whatever changed, it changed in the runtime, not the docs.

A concrete additional question for the team:

Has the byte accounting changed to count compressed-on-the-wire bytes vs decompressed application bytes (or vice versa) in a recent runtime update? A change in which side of gzip is counted would silently shift quota consumption by 5-10× without any documentation change being needed.

The Apr 20 docs update with no behavioral entries, combined with simultaneous onset across unrelated codebases, strongly suggests this is a runtime-side enforcement change that wasn’t release-noted. Acknowledgement that the limit exists and what unit it’s measured in (bytes/window? requests/window? something hybrid?) would unblock everyone here from guessing at the right mitigation.

Thanks.

7

Same issues here. Tried the back off as well as creating a new web app, neither of which helped with consistency. We have a similar set up that was described above. I have been unsuccessful in finding a workaround.

8

Same, It might work for 20 requests, then stop, and then start working again after 5 minutes. It crashes on different requests, even though all requests are 2–3 KB. There are 300 requests per day.

9

Hi everyone,
I’m experiencing the exact same issue starting recently.

My script has been running reliably for months without any changes, and suddenly I began getting the error:

“Bandwidth quota exceeded. Try reducing the rate of data transfer”

What’s confusing is that:

  • I am well below the documented quotas (both in number of requests and payload size)

  • The error does not match any official quota listed for UrlFetchApp

  • The issue appeared suddenly, without any modification on my side

In my case, the script:

  • Makes multiple UrlFetchApp.fetch calls to external APIs (shipping providers)

  • Does not exceed daily limits or per-request size limits

This makes me suspect there is:

  • A newly introduced undocumented bandwidth/throughput limit (e.g. bytes/sec or requests burst)

  • Or some kind of rate limiting on Google infrastructure/IP level

I can confirm that reducing the request frequency (adding delays) seems to mitigate the issue, which further supports the idea of a hidden throttling mechanism.

Would be great to get clarification from Google on:

  • Whether a new bandwidth/throughput quota has been introduced

  • What the actual limits are

  • And if there are recommended best practices to avoid hitting this error

Thanks :+1:

10

Hey,

joining this, since we are heavily using Appscript and are suddenly also facing this issue since this week. This has quite some impact on our workflows, and workarounds (spreading requests) are working but not quite well. The issue is that now we have to deal with the script running time vs the bandwith quota.

Same regression here, started for us 2026-04-21. We run 14 Google Apps Script projects under several Workspace accounts, all hitting ClickUp’s REST API and a self-hosted Laravel API of ours. Both started throwing Bandwidth quota exceeded within hours of each other, including on tiny POSTs around 1 KB. muteHttpExceptions: true does not suppress it. Same call retried 5 to 15 seconds later usually succeeds.

A few findings that might help narrow the trigger.

Bursts look like the cause, not totals. We have failures with cumulative daily traffic under 5 MB. UrlFetchApp.fetchAll([...]) with 5 or more requests per call trips the error far more often than the same requests issued sequentially with 50 ms gaps.

Concurrency across projects matters. When two of our scripts run in the same minute, both fail much more often than either does alone. Same Workspace account, different script IDs. The bucket looks per-account, not per-project.

Mitigations we tried: jittered backoff with retry helps small imports but the bucket depletes faster than 14 seconds replenishes it. Chunked 5-wide fetchAll with 250 ms gaps still trips on bigger projects. Fully serial with 1500 ms between calls is robust but hits the 6-minute execution kill on bigger imports. We landed on persist-and-resume: stash unfinished work in Script Properties when the quota throws, refuse new runs for 60 seconds, drain on next run. Our API is idempotent so replays are safe.

Anyone heard back on #505172128?

Best,

Thomas

11

+1 — same error, different surface (standard Apps Script, not Ads Scripts).

We have a script that’s run unchanged for ~2 years across 50+ client sheets. It uses UrlFetchApp to hit sheets.googleapis.com/v4/spreadsheets with a service account token. First failure was April 27, 2026:

Exception: Bandwidth quota exceeded: https://sheets.googleapis.com/v4/spreadsheets/[ID]/values/Tracking%20Summary!A1:H12. Try reducing the rate of data transfer.

The failing call was a values.update PUT to a 12-row x 8-column range — nowhere near any documented size limit. A full run is roughly 22 UrlFetchApp calls to the Sheets API over ~30 seconds. Two prior calls in the same run completed successfully; the third failed.

This matches the original report precisely: no code change, longstanding call pattern, sudden onset, error doesn’t map to any documented quota.

Thomas’s observation about the bucket being per-account rather than per-project is particularly relevant for us — we have multiple end users running this script manually, and the failures appear consistent with a shared bucket across concurrent runs rather than a per-script issue.

Confirms this isn’t an Ads Scripts–specific change. Would appreciate clarity from Google on whether enforcement changed around April 20.

12

Same error from a different destination (HubSpot CRM API),
destination logs confirm calls never arrived

Adding a corroborating data point from a separate Apps Script project that
hit the identical error today (Apr 28 2026, ~13:31 UTC). Different account,
different destination domain, different use case — same error format and
same “appeared out of nowhere” pattern.

Environment

  • Google Workspace account (paid, well-established)
  • Standalone Apps Script project (not Ads Scripts)
  • Single user, ~3-5 time-driven triggers per day
  • Destination: api.hubapi.com (HubSpot CRM v3 search endpoints)
  • Daily call volume: ~85-200 calls/day average over the past 30 days
    (well under the documented 100K/day Workspace ceiling)

Error received
Exception: Bandwidth quota exceeded:
https://api.hubapi.com/crm/v3/objects/emails/search.
Try reducing the rate of data transfer.

Thrown by: UrlFetchApp.fetch()
Caller chain: runDiagnostics → getEngagementCount → hubspotPost (UrlFetchApp.fetch)

Key data point: destination confirms the call never arrived
Pulled HubSpot’s API call audit log for the integration’s private app token.
For Apr 28, only THREE successful calls are recorded (all 200 OK,
/calls/search), all in a 1-second window immediately preceding the failed
call. The /emails/search call that threw the error in Apps Script has no
corresponding entry on the destination side — confirming the throttle is
applied at Apps Script’s egress layer, not by the destination API.

7-day call breakdown on the destination (for context — well under any
documented limit):
Apr 22: 72 Apr 25: 30
Apr 23: 193 Apr 27: 119
Apr 24: 186 Apr 28: 3 (then throttled)
Zero non-200 responses across 4,623 logged calls in the past 30 days.

Why this is informative
This rules out the destination API as the source of the error. The same
bandwidth quota error is appearing across:

  • Google Ads Scripts → ads endpoints (original post)
  • Standalone Apps Script → HubSpot CRM API (this report)

Suggesting the throttle is internal to UrlFetchApp itself, scoped at the
Apps Script execution layer rather than tied to any specific destination
domain. If it were domain-scoped, we wouldn’t expect to see it from such
different destinations under different accounts hitting different APIs.

Adding the same questions to the original — particularly:

  • What quota does this map to in the Apps Script internals?
  • Is enforcement per-user, per-domain, or per-execution?
  • Any chance of getting this added to the official quotas page so it’s
    measurable / debuggable?

Will update if a workaround surfaces. Currently testing exponential
backoff retry on the catch block as a mitigation.

13

Same issue here with some of our automations.. Really sucks to have this happening now and we are for sure not reaching bandwidth quotas… Does anyone know IF Google is doing anything about it?

14

Yep, same issue for me in Google Apps Script. Started today (about 2 hours ago, worked fine this morning), no code changes, and no differences in bandwidth but when using URLFetchApp it’s now coming back with the Exception: Bandwidth quota exceeded: Try reducing the rate of data transfer. Really frustrating because it’s causing the app (which has been running fine for years) to fail.

15

Yes - we are massively impacted by this too. Timelines are matching what everyone else is experiencing. Standard Google Apps Script

16

Same here! I have three clients experiencing this issue on apps script projects that haven’t been touched in several months.

17

Adding a data point that may help narrow down the rollout start date.

I run a Google Apps Script project that makes UrlFetchApp calls to two completely unrelated external services — FinViz and Tradier. Both started failing around the same time with no code changes on my end, which is what led me to suspect a platform-level change rather than either service rate-limiting me.

After checking my sheet-based error log, I can confirm the first Tradier UrlFetchApp failures occurred as early as 11:06AM PDT on April 19, 2026 — one day before the quotas documentation page was last updated (April 20) and four days before this thread was posted.

The errors I am seeing match exactly what is described here:

  • “Bandwidth quota exceeded: [url]. Try reducing the rate of data transfer.”
  • “Exception: Request failed for [url] returned code 429.”

The bandwidth error appears first, followed by the 429 on subsequent attempts to the same endpoint within the same execution — suggesting two distinct throttles being hit in sequence.

The fact that two unrelated external services began failing simultaneously, combined with the April 19 onset date aligning with the documentation update, would seem to clearly suggest a Google-side enforcement change rather than anything on the destination server end.

Hoping this helps establish the actual rollout start date. Happy to share additional details if useful.

18

Same error using Google Apps Script Workspace Account (for which I get a 30 min / execution).

Exception: Bandwidth quota exceeded: ... Try reducing the rate of data transfer.

Increasing the time between API calls (UrlFetchApp.fetch()) using Utilities.sleep() makes no discernible difference.

I’ll keep checking this thread, please post updates here if anyone gets a response/solution. Thank you

19

From Google Workspace Support: Please be assured, we have received multiple reports regarding this. Our engineering team is actively investigating and working on a resolution to address this issue as quickly as possible. We kindly ask for your patience and a little more time as our team works to resolve this. I will send you an immediate email update as soon as we receive confirmation that the issue has been fixed

20

Good news everyone!
The issue was marked as resolved on the official issue tracker by Google dev team.