Google Apps Script Quota Limits 2026 — Every Error, Every Fix

If your automation just stopped mid-run, you have hit a quota limit. Here is exactly which one and how to fix it — free, no upgrade required, works at any order volume.

Quick answer — the numbers that matter in 2026: Both consumer (free) and Google Workspace accounts get a 6-minute maximum execution time per script run — the old 30-minute Workspace limit no longer applies. Consumer accounts are capped at 90 minutes of trigger runtime per day; Workspace accounts get 6 hours of trigger runtime per day. UrlFetch calls are capped at 20,000 per day on consumer accounts (100,000 on Workspace). These are the hard limits that cannot be increased — they are why Autocrat, Sheets automations, and document workflows fail at scale.

If you have ever seen “Service invoked too many times”, “Exceeded maximum execution time”, or “Could not obtain lock”, you already know the symptom. This guide explains the exact numbers behind those errors, when they appear by account type, and what actually works when order or document volume gets serious.

What Are Google Apps Script Quotas?
Google Apps Script quotas are hard limits on how much work a script can do. They exist to protect shared infrastructure — stopping one workflow from consuming resources that affect thousands of other users. Quotas appear across four layers, and they all apply simultaneously:

User-level quotas — tied to the Google account running the script. Consumer and Workspace accounts have different ceilings.
Project-level quotas — tied to the Apps Script project itself. Concurrent executions are capped here.
Service quotas — Gmail, Sheets, Drive, UrlFetch, and other services each have their own daily limit.
Execution quotas — limits on how long a single run can take and how much total runtime is consumed in a day.
The critical point is that these limits stack independently. A workflow can be fine on execution time but fail on service call rate — which is why the same script can work perfectly for a small operation and break as soon as volume rises.

Google Apps Script Execution Time Limit (6 Minutes) & Official Documentation
These are the official limits as of April 2026. Google does not announce changes widely — they update the quotas page without notice, which is why searches for “quotas 2026” are so common.

1. Max execution time Consumer: 6 minutes Workspace: 6 minutes A single script run on a free Google account is hard-stopped after 6 minutes. The 30-minute limit some older guides cite was retired — there is no longer any per-execution headroom from upgrading to Workspace.
2. Trigger runtime per day Consumer: 90 minutes Workspace: 6 hours Total combined runtime of trigger-driven executions per day. Once exhausted, triggered scripts stop until the quota resets 24 hours after the first request. Manual runs are not counted against this cap.
3. UrlFetch calls per day Consumer: 20,000 Workspace: 100,000 Hits this ceiling faster than expected when automations check external APIs (Shopify webhooks, tracking endpoints) on every order.
4. Document service calls Consumer Limit: 30 per minute Calls to Google Docs or Drive in any rolling 60-second window. Autocrat-style workflows hit this quickly.
5. Quota reset window Resets: 24 hours rolling Per Google's documentation, quotas are per user and reset 24 hours after the first request — a rolling window, not a fixed midnight cutoff. Consumer vs Workspace — when to upgrade: Upgrading to Workspace does not raise the 6-minute per-execution ceiling. What Workspace does raise is the daily headroom: trigger runtime (90 min → 6 hr), UrlFetch calls (20,000 → 100,000), and email recipients (100 → 1,500).

Quota Comparison Table
Quota Type Consumer (free) Google Workspace Resets
Single execution time 6 minutes 6 minutes Per run
Trigger runtime/day 90 minutes 6 hours 24h rolling
UrlFetch calls/day 20,000 100,000 24h rolling
Document creates/day 250 1,500 24h rolling
Email recipients/day 100 1,500 24h rolling
Concurrent executions 30 30 Per moment
Script properties size 500KB 500KB Persistent
Why Quota Limits Break Your Automations
Quota failures are rarely random. They follow predictable patterns based on four root causes:

Burst processing — too many reads, writes, or document operations concentrated in one short window.
Trigger overlap — multiple time-based or event-based triggers fire before the previous execution finishes.
Large batch size — one job attempts to process more rows than a single 6-minute execution can handle.
Hidden retry loops — failed executions trigger automatic retries, accelerating the failure spiral.
The honest truth about Apps Script quotas: they are a capacity problem, not a coding problem. You can reduce the pain with better architecture — but you cannot build unlimited scale on top of limits that Google has fixed at the infrastructure level.

Common Quota Errors and What They Mean
Error Message Quota Breached Immediate Cause
Service invoked too many times Service call rate Too many calls to Sheets, Docs, Drive, or Gmail in a short window
Exceeded maximum execution time 6-min execution ceiling Single run took longer than 6 minutes — script hard-stopped mid-execution
Could not obtain lock Concurrent execution Two runs tried to access the same resource simultaneously
Quota exceeded Daily service limit UrlFetch, document creates, or email sends hit the daily cap
How to Stay Under Quotas Without Breaking Your Workflow
These six techniques reduce quota pressure and can sustain most medium-volume automations on consumer accounts.

Batch smaller chunks — process 50–100 rows per run instead of everything at once.
Reduce API calls aggressively — cache sheet values at the start using getValues() once, operate on the array in memory, then write back with a single setValues() call.
Stagger triggers — separate time-based triggers by at least 5–10 minutes to prevent overlapping executions.
Persist state with PropertiesService — save progress checkpoints so a timed-out script can resume from where it stopped.
Add exponential backoff — when a service call fails, wait and retry with increasing delays.
Use LockService deliberately — acquire a lock at the start of any execution that touches shared data.
Why Autocrat Specifically Hits Quota Limits
Autocrat is one of the most popular document generation tools for Google Sheets — and one of the most quota-sensitive. If you are generating contracts, invoices, or certificates from Sheets rows, you will hit quota limits earlier than almost any other workflow.

Each Autocrat document generation triggers multiple service calls in sequence: it opens Drive, reads the template, creates a new document, writes merged data, converts to PDF, saves to Drive, and optionally sends via Gmail. That is 5–8 service calls per row. At 30 document service calls per minute, Autocrat can reliably process around 4–5 documents per minute — or roughly 25–30 in a single run before the service rate limit triggers.

The Structural Fix
The reliable solution is moving document generation off Google's shared execution environment entirely. Instead of Autocrat running inside Apps Script on Google's public quota pool, the workflow should run through a dedicated Make.com scenario that calls the Google Docs API directly via a private HTTP connection. Make.com runs are not subject to Apps Script execution time limits or the 250-documents-per-day consumer limit.

When You Have Outgrown Apps Script Entirely
The signal is usually obvious: document generation starts missing rows, order sync gets delayed, or the workflow behaves differently depending on the time of day. That last symptom — time-dependent behaviour — is the clearest sign of a daily quota problem.

Keep lightweight logic close to the spreadsheet (change detection, simple calculations) and move heavy lifting to a system built for throughput (Make.com, a Cloud Function, or a dedicated API lane).

Apps Script detects the event. Make.com does the processing. The result lands back in Sheets. This pattern removes the quota ceiling from every expensive operation.