Table of contents
Somebody built it three years ago. It copied orders from a Google Form into a sheet, sent the warehouse an email every morning and pushed deliveries into the team calendar. Nobody knows how it works, and this morning it stopped. The sheet shows “Exceeded maximum execution time”, or the email says a trigger failed, or the person who wrote it left in June and everything they owned went quiet.
This is a Google Apps Script problem, and it is one of the most common support requests we get from companies where the automation has no assigned owner. This article explains the three failure types we see most, how to diagnose each one safely, and the point at which the honest advice is to move the automation somewhere else. Quotas and behaviour checked against Google’s Apps Script documentation on 9 September 2026.
First, find out what actually failed
Open the spreadsheet or document the script lives in, then Extensions, Apps Script. If the automation is a standalone project rather than a script bound to the sheet, find it at script.google.com instead. On the left, Executions lists every run with its status and error message, for the account you are signed in with. Sort by status and note the last successful run. You will usually see one of three things: red rows saying Exceeded maximum execution time, rows with an authorisation or permission error, or no rows at all in the last few days. The last one is not proof that the trigger is gone; it can also mean you are looking at the wrong project, the wrong account, a filter, or a trigger whose owner’s account is no longer active. Check Triggers (the clock icon) before concluding anything.
Failure 1: the 6-minute limit
A normal Apps Script execution may run for 6 minutes, then Google stops it. This applies to consumer and Workspace accounts alike. Simple triggers such as onEdit and custom functions in cells have a much shorter limit of 30 seconds. The most common reason a script that used to finish now hits the limit is growth: three years ago the sheet had 400 rows and the loop finished in 40 seconds, now it has 40,000 rows and the same loop needs 20 minutes. It is not the only reason, though; a slow external API, a loop that reprocesses everything, or a formula-heavy sheet can do the same, so check the Executions log for how long the runs took before they started failing. Related daily quotas bite in the same way: total trigger runtime per day (90 minutes for consumer accounts, 6 hours for Workspace), email recipients per day (100 for consumer accounts, 1,500 for Workspace) and URL fetch calls. Quotas are per user and Google adjusts them, so treat the numbers as this year’s.
Fixes, from cheapest to most work
- Stop reading and writing cell by cell. The single biggest cause. A script that calls
getValue()andsetValue()inside a loop talks to the spreadsheet service on every iteration. Reading the whole range once withgetValues(), working in memory and writing back once withsetValues()is dramatically faster; Google’s own best-practice page shows the same job going from over a minute to about a second. Most scripts that hit the limit stop hitting it after this change alone. - Process only what is new. Keep a “processed” column or a timestamp and skip rows the script already handled. Mark a row as processed only after its work has actually succeeded, otherwise a failed run leaves rows marked done that never were. A daily job that reprocesses the whole history is the second most common cause.
- Batch across runs. Save progress in
PropertiesService, stop cleanly before the limit and let the next trigger continue where the last one ended. Add a lock (LockService) so two runs cannot overlap and double-send emails. Reliable, but somebody has to understand the code. - Archive the sheet. Move rows the business no longer works with into a separate file. Faster script, faster spreadsheet, happier users.
Failure 2: permission and authorisation errors
The messages read “This app isn’t verified”, “Google hasn’t verified this app”, “This app is blocked” or “Authorization is required to perform that action”. They mean different things.
- “This app isn’t verified” or “Google hasn’t verified this app”. The script asks for access to Gmail, Drive or Calendar and Google shows a warning because the OAuth project has not been through verification. Projects owned and used inside one Workspace organisation are normally exempt from verification, so if you see this warning for what you believe is an internal script, stop and check: who owns the Apps Script project, which Cloud project it is attached to, and exactly which permissions (scopes) it asks for. A script written by an agency or a former contractor may live in their account. Only once the owner and scopes are confirmed should an administrator authorise it; do not train staff to click through “Advanced” as a habit.
- “This app is blocked”. Most often your Workspace administrator has restricted third-party app access, in which case the fix is in the Admin console: Security, Access and data control, API controls, Manage third-party app access, and allow this specific script for the users who need it. Read the full error code first, because the same words can also come from an OAuth client configuration problem. Do not switch the control off for the whole organisation, and do not blanket-trust every “internal” app either; allow the one you have checked.
- “Authorization is required to perform that action”. The script’s permissions were revoked, or it now needs a scope it did not have before. Re-authorise by running a function by hand, but choose it carefully: an arbitrary function may send emails or overwrite rows. Use a harmless one (a small
function authorise() { Logger.log('ok'); }that touches the same services is the clean way), and run it as the account that owns the triggers. - Nothing runs since a colleague left. Installable triggers run as the person who created them, and when that account is suspended or deleted they stop. Transferring the file to a current employee does not transfer the triggers: the new owner cannot even see triggers another user installed. So inventory what the script was supposed to do and when, create new triggers under a current account, check the Executions log for the first runs, and watch for duplicates if the old account is only suspended and might be reactivated. For anything the business depends on, create the triggers from a dedicated Workspace user account (“automation@”) with its own licence and 2-step verification, owned by IT rather than by whoever wrote the script. That is a managed user account, not a Google Cloud service account; Apps Script triggers cannot run as a service account.
Failure 3: something Google changed
Rarer, but real. Apps Script’s old Rhino runtime is being shut down (Google set 31 January 2026 as the earliest shutdown date), and very old scripts that were never migrated to the V8 runtime can fail or behave differently. Open the project settings and check which runtime it uses; Google’s V8 migration guide lists the constructs that break. Occasionally a Google service changes behaviour and a script that relied on it breaks. Check the Executions log for a new error you have never seen and search the exact message. If it appeared for many people on the same day, it is probably on Google’s side, but “wait a day” is only acceptable if the business can; otherwise switch to the manual fallback and keep the logs.
When to move off Apps Script
Apps Script is excellent for glue: a form that fills a sheet, a sheet that sends a reminder, a calendar that mirrors a roster. It is the wrong tool once any of these is true:
- It still runs into the 6-minute limit after the fixes above, or its daily quota usage is close to the ceiling.
- The business stops if it fails, and nobody would notice for a day, because there is no monitoring and no error recipient who still works here.
- More than one person has edited it and none of them can explain it.
- It has become the company’s order system, inventory system or CRM, with several people writing to the same sheet at once. Sheets is not a database, and a script does not make it one.
Row counts alone do not decide this; 40,000 rows processed in batches is fine, 400 rows with concurrent writers and no error handling is not. At that point the options are, in order of effort: clean up the existing script and give it an owner, monitoring and a lock; keep the sheet as the interface but move the heavy processing to a small Cloud Run service; or move to an off-the-shelf business system that already does the job. None of these is self-maintaining. A Cloud Run service nobody watches is exactly as dark as a script nobody watches. We say this as a company that has written and inherited a great many Apps Scripts: small, clearly bounded ones with a named owner are the ones that keep working.
Frequently asked questions
How long can a Google Apps Script run?
6 minutes per normal execution, for both consumer and Workspace accounts. Simple triggers and custom functions in a cell have 30 seconds. Daily totals for trigger runtime, email recipients and URL fetches also apply and are higher on Workspace.
Why did my Apps Script stop when an employee left?
Installable triggers run as the person who created them. Suspending or deleting that account stops them, and nobody else can see or edit those triggers. Recreate them under a current account, ideally a dedicated automation user, and check for duplicate runs.
Can a Workspace admin see which scripts are running in the company?
Partly. The Admin console shows OAuth apps and their scopes under API controls, and the Google Cloud console lists Apps Script projects that were linked to a Cloud project. Scripts inside individual sheets are not centrally inventoried, which is a good argument for keeping business-critical ones in a shared drive owned by IT.
Related articles
- Google Workspace account suspended. What now?
- How to actually get Google Workspace support when something breaks
- Managed IT services for Google Workspace companies
If a script your business depends on has stopped, send us the error text from the Executions log, the time of the last successful run and a sentence on what it is supposed to do; with that, we can usually say quickly whether it is a small fix or a rebuild, and agree the scope before touching anything.
Automation failed and nobody owns it? We assess the workflow, its triggers and execution accounts, then scope a repair and a maintenance plan with a named owner. Book a free 30-minute audit or call +371 22 30 50 90.
