Google Apps Script · Quotas · 2026 Limits

Google Apps Script Quotas & Limits (2026) — Every Error, Every Fix (Free)

Google Apps Script limits every script to six minutes of execution per run, with 90 minutes of daily trigger runtime on consumer accounts and six hours on Workspace. These limits cannot be raised by payment or configuration — they are fixed at Google's infrastructure level, which is why heavy Autocrat and Sheets automations eventually fail.

Updated August 2026 · Google Apps Script · Quotas · Automation Scaling

Some links below are affiliate links (marked sponsored). They fund the free guides and never change a recommendation — our default pick on this page is a free tier. How we test & disclose →

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.

The Exact Google Apps Script Quota Limits in 2026

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.

Every Google Apps Script Quota and Limitation (2026) — Complete Table

The seven figures above are the ones that break automations. Google publishes 22 daily quotas and 18 fixed limitations in total, and the rarer ones — Slides created, JDBC failed connections, URL Fetch header size — are exactly the ones nobody can find when a script starts failing. Here is the complete set, both account types, nothing omitted.

Verified 23 August 2026 against Google Apps Script — Quotas for Google Services. Google does not version that page, so the check date is the only provenance available — these are re-verified quarterly and every change is logged at the foot of this section.

Daily quotas — reset on a 24-hour rolling window

Hard limitations — fixed, and identical on both account types unless stated

Two things worth noticing in the complete set. Only three limitations differ between account types at all — email body size, and the two email-recipient quotas. Everything else in the limitations table is identical whether you pay Google or not, which is why “upgrade to Workspace” is such poor advice for a script that is timing out. And document, presentation and slide creation all share the same 250/day consumer ceiling — if one workflow generates all three, they do not pool, but they do fail on the same day.

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.

Common Quota Errors and What They Mean

Each error message maps to a specific quota breach. Knowing which limit you hit tells you which fix applies.

If “Service invoked too many times” is your specific error, the fix steps differ from other quota errors. The step-by-step fix guide covers each scenario with the specific code patterns that stop the error at its root cause.

If your quota errors are tied to Shopify order volume — particularly inventory sync or order logging workflows — the Stocky Swap free replacement routes every order through Make.com directly to Google Sheets, bypassing Apps Script execution entirely. No quota ceiling, no 6-minute limit, no document create cap. Deploy free in 4 minutes →

Will Your Script Hit a Quota? Work Out Which Ceiling Binds First

Google publishes the limits. It does not tell you whether your script is going to reach them, and that is the only question that matters at 2am when a batch dies halfway through. Three ceilings can stop an Apps Script job and they bind in different orders depending on what the script does. This works out which one you reach first.

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. They are mitigation strategies — not architectural solutions for serious scale.

• 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.

The Resumable Batch Pattern — Working Code That Survives the 6-Minute Wall

Everything above reduces how often you hit the ceiling. This is the pattern that makes hitting it survivable: the script processes what it can inside a time budget, writes down where it got to, schedules itself to continue, and picks up from the same row on the next run. A job that needs forty minutes finishes across nine executions instead of dying at six.

Most published versions of this leak triggers. They create a new one-shot trigger on every resume without deleting the one that just fired — and because a script is capped at 20 triggers (see the limitations table above), a long job kills itself with “This script has too many triggers” around the twentieth chunk. The version below deletes its own triggers before creating the next, holds a lock so two chunks can never run at once, and bounds its retries so a permanent error cannot loop until the daily quota is gone.

const HANDLER        = 'runResumableBatch';   // must equal this function's name
const CURSOR_KEY     = 'batch_cursor';
const RETRY_KEY      = 'batch_retries';
const TIME_BUDGET_MS = 4.5 * 60 * 1000;       // stop at 4:30 of the 6:00 ceiling
const CHUNK_ROWS     = 200;                   // rows per read/write pair
const MAX_RETRIES    = 3;

function runResumableBatch() {
  const started = Date.now();
  const props   = PropertiesService.getScriptProperties();

  // Never let two chunks run at once. tryLock, not waitLock: a queued chunk
  // would burn its own execution time sitting in the queue.
  const lock = LockService.getScriptLock();
  if (!lock.tryLock(5000)) {
    console.log('Another chunk holds the lock. Exiting.');
    return;
  }

  try {
    // Delete the one-shot trigger that fired this run, plus any strays. A
    // time-based trigger created with .after() is NOT removed automatically.
    clearOwnTriggers_();

    const sheet   = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('Orders');
    const lastRow = sheet.getLastRow();
    let   cursor  = Number(props.getProperty(CURSOR_KEY) || 2);  // row 1 = headers

    while (cursor <= lastRow) {
      // Check the clock BEFORE starting a chunk, never during. A chunk that
      // starts must be allowed to finish, or its rows are read and not written.
      if (Date.now() - started > TIME_BUDGET_MS) {
        props.setProperty(CURSOR_KEY, String(cursor));
        scheduleNextChunk_();
        console.log('Budget reached at row ' + cursor + '. Next chunk scheduled.');
        return;
      }

      const rows   = Math.min(CHUNK_ROWS, lastRow - cursor + 1);
      const values = sheet.getRange(cursor, 1, rows, 3).getValues();   // ONE read
      const output = values.map(processRow_);
      sheet.getRange(cursor, 4, output.length, 1).setValues(output);   // ONE write

      cursor += rows;
      props.setProperty(CURSOR_KEY, String(cursor));   // checkpoint after the write
    }

    props.deleteProperty(CURSOR_KEY);
    props.deleteProperty(RETRY_KEY);
    console.log('Finished at row ' + (cursor - 1) + '.');

  } catch (err) {
    // A thrown error must not strand the batch halfway. Reschedule — but bound
    // it, or a permanent failure retries until the daily runtime quota is gone.
    const attempts = Number(props.getProperty(RETRY_KEY) || 0) + 1;
    if (attempts <= MAX_RETRIES) {
      props.setProperty(RETRY_KEY, String(attempts));
      scheduleNextChunk_();
      console.log('Chunk failed (attempt ' + attempts + '). Retry scheduled.');
    } else {
      props.deleteProperty(CURSOR_KEY);
      props.deleteProperty(RETRY_KEY);
      console.log('Giving up after ' + MAX_RETRIES + ' attempts. Cursor cleared.');
    }
    throw err;   // still surface it, so the execution shows as failed

  } finally {
    lock.releaseLock();
  }
}

// Your per-row work. Must return a one-cell array to match the setValues range.
function processRow_(row) {
  return [row[0] + '-' + row[1]];
}

function clearOwnTriggers_() {
  ScriptApp.getProjectTriggers()
    .filter(function (t) { return t.getHandlerFunction() === HANDLER; })
    .forEach(function (t) { ScriptApp.deleteTrigger(t); });
}

function scheduleNextChunk_() {
  ScriptApp.newTrigger(HANDLER).timeBased().after(60 * 1000).create();
}

Why each piece is there

• TIME_BUDGET_MS is 4:30, not 6:00. The check happens between chunks, so the budget must leave room for the slowest possible chunk plus the checkpoint and the trigger call. Setting it at 5:50 means the run dies inside a chunk with rows read and not written.
• The clock is checked before a chunk, never inside one. A chunk that has started must finish, or you get the exact partial-write failure the whole pattern exists to prevent.
• tryLock, not waitLock. A chunk that queues behind another spends its own six minutes waiting. Better to exit and let the scheduled trigger handle it.
• clearOwnTriggers_() runs first. One-shot .after() triggers persist after firing. Without this the script accumulates one per resume and stops at the 20-trigger cap — a quota failure caused by the fix for a quota failure.
• The checkpoint is written after the setValues, not before. Checkpoint first and a crash between the two loses the chunk silently; checkpoint after and the worst case is one chunk processed twice, which is recoverable.
• Retries are bounded. An unbounded reschedule on a permanent error — a bad reference, a deleted sheet — will consume the entire 90-minute daily trigger allowance overnight and take every other automation on the account down with it.

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.

• Trigger in Apps Script — lightweight event detection only
• Process in a dedicated execution layer — Make.com, a Cloud Function, or a dedicated API lane
• Write results back only after the heavy work is complete

Best Architecture for Scale

Keep lightweight logic close to the spreadsheet — change detection, simple calculations, notification sends — and move heavy lifting to a system built for throughput.

Apps Script detects the event. Make.com or a dedicated service does the processing. The result lands back in Sheets. This pattern removes the quota ceiling from every expensive operation. The Make.com for Shopify complete guide covers exactly how to set this up from scratch.

Frequently Asked Questions

Final Takeaway

Google Apps Script quotas in 2026 are not a mystery once you know the numbers: 6 minutes per execution, 90 minutes per day, 20,000 UrlFetch calls on a consumer account. They are clear, fixed, and cannot be negotiated with. If your automation is stable, the limits are irrelevant. If your workflow is growing, the limits become the ceiling.