Free tool · no sign-up

Free Google Apps Script error decoder

Paste an Apps Script error. Executions log, daily-failure email, editor dialog. Get the cause, the common pitfalls, and the exact fix. No API doc spelunking.

Paste your Apps Script error

From the Executions log, from the daily-failure email, or copied straight from an Apps Script editor error dialog. Stack traces are fine.

Try a sample:
authorization-required

Script needs Google authorization

Apps Script is asking for permissions you haven't granted yet. The handler can't run until you run the installer / handler manually once and click through the consent dialog.

Common causes
  • First time the script is running on this account
  • Script accesses a new API (UrlFetchApp, GmailApp, SpreadsheetApp) added since you last authorised
  • Authorization was revoked from your Google account's third-party access list
Fix: Open the Apps Script editor, pick the installer / handler function from the dropdown at the top, click Run. When the “Authorization required” dialog opens: Continue → pick the account → Advanced → Go to (unsafe) → Allow. The “unverified” warning shows because the script is yours, not Google's — review the OAuth scopes before clicking Allow.
Full reference

Every Apps Script error this decoder recognises.

PatternWhat it means
authorization-requiredScript needs Google authorization
service-invoked-too-many-timesDaily quota for an Apps Script service hit
max-execution-timeScript ran longer than 6 minutes
urlfetch-failedUrlFetchApp couldn't reach the endpoint
server-errorTransient Google Apps Script error
reference-errorScript references an undefined variable or function
type-error-undefinedTried to read a property off undefined
lock-timeoutLockService couldn't acquire a lock in time
range-not-foundReferenced sheet or range doesn't exist
daily-failures-emailDaily summary of Apps Script failures
trigger-not-firingTrigger exists but hasn't fired
The Apps Script error vocabulary

Why these messages are so unhelpful out of context

Apps Script's error messages are designed to be exact, not friendly. Authorization is required to perform that action doesn't tell you which action or why now: the answer is “you added UrlFetchApp to a script that previously only read the form, so the scope set changed”, but that's never in the error itself. Service invoked too many times for one daysounds like a counter you could reset, but it's actually a daily quota tied to your Google account. Exceeded maximum execution timeis a 6-minute hard timeout that Workspace users get 30 minutes for and free users can't raise.

The decoder unpacks each one into the action you need to take. The eleven patterns covered cover what we actually see in production form-to-Slack pipelines. Common, rough frequency:

  • Authorization is required, first-time setup. The unverified-app warning trips people; we explain the Advanced → Allow path.
  • Request failed for hooks.slack.com. Slack rejected the post. The decoder points you at our webhook checker for the Slack-side diagnosis.
  • Cannot read properties of undefined, usually a sheet-bound vs form-bound trigger mismatch (different event shape).
  • Service invoked too many times for one day, quota hit. Pacific midnight reset; we suggest the cap + retry + relay options.
  • Exceeded maximum execution time, script over 6 minutes. We point at chunking patterns for batch jobs.
When to reach for this

The three moments

  • An Executions log row is red. Click it, copy the Error column, paste here. You get the explanation without reading the full stack.
  • The daily-failures email arrived. Paste a row (or the whole email body) — the decoder finds every known pattern in the message and shows a card per failure. Useful when several scripts failed and you want to triage quickly.
  • The editor red-dialogged you mid-Run. The dialog text is enough, paste just the message and the decoder maps it to the fix you need before retrying.
How this fits with the other Apps Script tools

Three tools, one workflow

When something's wrong, the path is usually: identify the symptom layer, then drill in.

  • If the trigger never fires, the error decoder won't help, there's no error to decode. Use the trigger checker to validate the function / source / event-type combination instead.
  • If the script runs but throws, the decoder is the right tool. Paste the error, get the fix.
  • If the script runs, doesn't throw, but Slack shows nothing, the Slack-side is the problem. The Slack error decoder and webhook checker cover that surface.
FAQ

Frequently asked questions

What does the decoder do?

It takes any Apps Script runtime error and tells you what it means, why it usually happens, and how to fix it. Apps Script's error vocabulary is small but cryptic — 'Authorization is required to perform that action' doesn't obviously translate to 'click Run once and follow the consent dialog' until you've done it a few times. This decoder bridges that gap.

How is this different from the Slack webhook error decoder?

Different layer. /tools/slack-webhook-error-decoder handles Slack's response codes (no_service, invalid_payload, etc.), what Slack sends back when you POST. This one handles Apps Script's own runtime errors, what Apps Script throws when your script can't even reach Slack (authorization missing, quota hit, UrlFetchApp failed, TypeError on undefined). They're complementary: if Slack rejects, use the Slack decoder; if your script never gets that far, use this one.

Where do I find the error to paste?

Three places. (1) The Apps Script Executions log, left sidebar of the editor, line-graph icon, click a failed row to see the full stack. (2) Daily failure emails Google sends to the script owner aggregating failed runs in the past 24h. (3) The error dialog that pops up when you Run a function manually from the editor. Stack traces and aggregated summaries both work, the decoder substring-matches across the full input.

What errors does it recognise?

Eleven patterns covering the bulk of production failures: Authorization required, quota exceeded (service invoked too many times), max execution time (6-minute timeout), UrlFetchApp request failed, transient Google server errors, ReferenceError (undefined symbols), TypeError (reading property of undefined), LockService timeouts, range / sheet not found, the daily-failures summary email format, and trigger-not-firing diagnostics.

Can I paste multiple errors at once?

Yes, if your input contains multiple known patterns (common when pasting a daily summary email that lists several failures), the decoder shows a card for each. Each pattern is independent; finding 'authorization required' alongside 'cannot read property of undefined' produces two cards because they're two different root causes that happened to coincide.

Does it send anything to Google?

No. Everything runs in your browser, the error text never leaves your machine. There's nothing to send: we're parsing what Apps Script already gave you.

What if my error isn't matched?

You'll get a 'no known pattern matched' message. Two next steps: (1) paste more of the stack trace, many Apps Script errors carry the actual cause a few lines below the headline; (2) check the underlying API at developers.google.com/apps-script, particularly common for newer services (Calendar, Drive Files, Gmail aliases) that have their own error vocabulary.

Will RouteForms surface these errors automatically?

Some, indirectly. RouteForms's delivery log records every Slack post with its Slack-side response, so 'UrlFetchApp succeeded but Slack rejected' shows up cleanly. Apps Script's own errors (authorization missing, quota exceeded) still surface in the Apps Script Executions log if you're using a self-hosted script. RouteForms's managed installer minimises authorization friction by asking for the minimal scope set the first time you run it.

Stop reading Apps Script error messages

RouteForms takes Apps Script out of the critical path, installer handles auth, delivery happens server-side, errors surface in a friendly log. Free for 30 responses a month.