Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A Google Apps Script that works when you click Run can still fail later because a trigger runs under a different account context, receives different data, lacks a newly required authorization, or reaches a quota or service problem. Start with the failed run in Executions, reproduce the same conditions, then use logs or breakpoints to isolate the cause. A successful run with incorrect output calls for checking inputs and logic, not just looking for an exception.
Why does my Google Apps Script work manually but fail on a trigger?
A manual editor run and a trigger run are not necessarily equivalent. Installable triggers run as the account that created them, and an event-driven trigger receives an event object with context about the event. What identity information is available can depend on the trigger’s authorization mode. Check Google’s documentation on installable triggers and event objects when comparing the two paths.
Authorization is a common difference. A trigger cannot pause in the background to ask someone to approve new permissions. If your updated code needs additional scopes, the trigger creator must authorize them manually by running a function in the editor and responding to the authorization prompt. See Google’s authorization guide.
- Open the trigger’s failed execution and note the function, error, and time.
- Check which account created the installable trigger; that account is the one whose permissions the trigger uses.
- If you added a service or scope, have the trigger creator run the code manually and complete authorization.
- Compare the manual test with the trigger event, input data, and authorization mode rather than assuming they share the same context.
For identity-related failures, Google advises checking the trigger event’s authMode and the guidance for that mode if Session.getActiveUser() or Session.getEffectiveUser() is unavailable. Workspace administrator policies may also restrict access.
#1 Best Overall
- The Google Workspace Bible: [14 in 1] The Ultimate All in One Guide from Beginner to Advanced Including Gmail, Drive, Docs, Sheets, and Every Other App from the Suite
- ABIS BOOK
How do I debug Google Apps Script?
Use a repeatable sequence: find the failing execution, classify what happened, reproduce its context, and inspect only the code and values needed to distinguish likely causes. Google’s troubleshooting guide distinguishes syntax errors from runtime errors: syntax problems are caught when saving, while runtime errors appear when code executes. A run can also finish without an exception and still return the wrong result.
- Open the execution record. In the Apps Script editor, select Executions and open the failed or timed-out run. Record its function, time, status, error text, and line number. For trigger failures, also check the failure notification.
- Classify the symptom. A reported runtime exception points to code or data reached during execution. If the run completed but the output is wrong, treat it as a logic or input issue and inspect the values that feed the affected operation.
- Reproduce the same path. Use the same function, data, account, and trigger event where possible. A manual run is useful, but does not prove that a trigger has the same identity or authorization context.
- Instrument a narrow area. Log relevant inputs, branch decisions, and service-call results with
Loggerorconsole. Avoid recording private user data unless it is necessary and appropriate. - Inspect state with breakpoints. Set a breakpoint before the suspect operation, run in debug mode, then step through the code and inspect variable values.
- Check constraints outside the code. Look for quota or runtime errors, authorization failures, Workspace policies, inaccessible account information, missing libraries, multiple signed-in Google accounts, or a temporary service outage.
- Verify the repair. Rerun the failing path and check both the execution status and the resulting output. If you changed required permissions, authorize them as the trigger creator before relying on the background run.
Where do I find Apps Script execution logs?
Open Executions in the Apps Script editor to find a particular run and its status, error, and associated logs. For quick development checks, the execution log is a convenient real-time view, but it is short-lived rather than a durable production log store.
Rank #2
For logs that need to remain available for days or help diagnose a multi-user production workflow, Google documents Cloud Logging. Unhandled exceptions can be logged with stack traces and appear in Error Reporting, which aggregates runtime errors. Some Cloud features require a standard, user-managed Cloud project and appropriate project access.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Method | Best use | Limitation |
|---|---|---|
Execution log with Logger or console |
Quick development checks and values from a run | Short-lived; not a persistent production log store |
| Execution history | Finding failed, timed-out, or unexpected runs and their context | It helps locate a run but does not, by itself, explain the cause |
| Debugger and breakpoints | Inspecting variables and stepping through a reproducible path | Generated code from eval() or new Function() is not shown as normal source |
| Cloud Logging | Retained logs and diagnosing multi-user production issues | Full use depends on Cloud project setup and access |
| Error Reporting | Aggregating runtime exceptions and stack traces | Exceptions need to be logged; access is through the Cloud project |
| Gemini in the editor | Getting a proposed explanation or code diff based on an error and surrounding code | Review the suggestion and rerun the script to verify it |
Why did my Apps Script stop working?
“Stopped working” can describe several different failures. The execution record and exact error help separate them: the fix for malformed data is different from the fix for missing permission or an unavailable service.
Different or malformed input
Valid JavaScript can fail at runtime when a value is missing, malformed, or outside the assumptions your code makes. A script may also finish normally but produce an unexpected result because it took a different branch or processed different data. Log the values at the boundary between input parsing and the operation that fails or produces the wrong output; use a breakpoint to inspect the branches if needed.
Authorization, account, or Workspace policy
A trigger may require a permission that has not been granted by its creator, or a Workspace administrator may restrict a service. A function that reads identity information may also behave differently under the trigger’s authorization mode. Use the execution error and event context to distinguish these cases.
Rank #4
Temporary service availability
Google lists temporary server unavailability among possible causes. Check the Google Workspace Status Dashboard if the error points to a service outage; do not treat a transient failure as proof that the code itself changed.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteCode generated dynamically
The editor cannot display dynamically generated JavaScript from eval() or new Function() as a normal source file. While stepping into that code, the debugger may show “Source code for the current line is not available.” That message does not necessarily end the debugging session; step out or resume until execution leaves the generated code.
Best Value
Did my script hit a quota or time limit?
Quota errors stop an execution with an exception. Google says quotas are per user, may differ between consumer and Workspace accounts, and reset 24 hours after the first request. Its live Apps Script quotas table warns that limits can change without notice, so check it for the account and service in question instead of relying on a remembered number.
In Google’s quota table as accessed in October 2026, the general script runtime limit is listed as six minutes per execution for both consumer and Workspace account columns. The same snapshot lists 30 seconds per execution for custom functions, 30 simultaneous executions per user, and 20 triggers per user per script for both account columns. These are point-in-time figures, not guarantees for every service, account, or future date.
- Read the full exception text in the execution record; it may name the service or limit reached.
- Compare the failing run’s duration and request volume with the live quota table.
- Check whether the issue is a per-execution runtime ceiling, a service-specific quota, or simultaneous activity by the same user.
- Recheck the quota table when the account type or service is uncertain, because Google can change limits without notice.
Can Gemini help diagnose an Apps Script error?
Gemini in the Apps Script editor can propose an explanation and code diff using an error and surrounding code. Treat that output as a suggestion, not a confirmed diagnosis: inspect the proposed change and rerun the same failing path to establish whether status and output are now correct. Google describes the feature in its Gemini in Apps Script guide.
Recommended Free Tools
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

