Why Did Your Google Apps Script Trigger Stop Running?

Detailed Explanation

A Google Apps Script that has run reliably for months and then simply stops — no error visible anywhere the user normally looks, no obvious change to the sheet, form, or script itself — is one of the more disorienting automation failures inside Google Workspace, precisely because nothing about the script necessarily changed. The cause is almost always one of three platform-level conditions, not a bug introduced into the code itself.

This is a distinct problem from writing the script in the first place — see what can you automate with Google Apps Script for what the platform does and how triggers work generally. This page covers what to do once an existing, previously working trigger has gone quiet.

The Three Common Causes

Execution quotas exceeded. Apps Script enforces a hard execution-time limit on any single run (commonly cited as around six minutes for most account types, though the current published number should always be checked against your account type), plus separate daily quotas covering total execution time and the number of trigger-based executions allowed per day. A script that grows slower over time — as a Sheet gains more rows, or a Gmail label accumulates more messages to process — can cross a time limit it was comfortably under when first built, or accumulate more daily runs than a lighter version of the same automation.

An unhandled error triggered Google's automatic disabling. If a time-driven trigger fails repeatedly across consecutive scheduled runs, Google Workspace automatically disables it as a protective measure, rather than letting it keep failing silently forever. The underlying error is often something environmental rather than a code typo: a linked spreadsheet, Doc, or external resource the script depends on was renamed, moved, deleted, or had its sharing permissions changed.

Authorization was revoked or needs re-granting. A script's permission to act on a user's Workspace data can be invalidated by the account owner's password changing, a Workspace admin's security policy review revoking third-party or script access, or — in a business context — the person who originally authorized the script leaving the company without ownership being transferred first. The script itself is unchanged; it simply no longer has permission to run.

Diagnosing Which Cause Applies

1. Open the Apps Script project's Executions log first. Every run — successful or failed — is recorded with a timestamp and, for failures, an error message. This is the fastest way to see exactly when the trigger stopped working and what error accompanied the last attempts, rather than guessing from downstream symptoms.
2. Check for a Google notification email around the time it stopped. A repeated-failure auto-disable typically comes with an email to the script owner explaining why — search for it before assuming there's no explanation available.
3. Compare current volume against the quotas for your account type. If the underlying data (rows, emails, calendar events) has grown significantly since the script was built, check current execution-time and daily-quota limits against what the script is now actually doing per run.
4. Confirm the script's authorization status directly in the Apps Script editor. A revoked or expired authorization typically surfaces clearly here, and re-running the authorization flow (or having the correct account owner do so) resolves it if this is the cause.
5. Check whether a linked resource still exists and is still shared with the script's account. A renamed, moved, or permission-changed Sheet, Doc, or Drive folder the script depends on is a common root cause behind an "unhandled error" that isn't obviously about the script's own logic.

Fixing It

Add explicit error handling and alerting inside the script itself, rather than relying on Google's automatic-disable behavior as the only signal something went wrong. A try/catch block that sends an email or logs to a monitoring Sheet the moment a run fails gives you a warning on the first failure, not after several consecutive ones have already caused a disable — see how do you add error handling and retry logic to a Google Apps Script automation for building this in from the start rather than retrofitting it after a trigger has already been disabled.

Re-authorize the script under the correct, currently active account once you've confirmed authorization is the cause, and — for a business-owned script — document who the authorizing account should be so a future employee departure doesn't silently break the automation again.

Reduce per-run workload if you're approaching the execution-time limit, by processing data in smaller batches across more frequent trigger runs rather than one long run trying to handle everything at once — this is the standard fix for a script that has simply grown alongside the data it processes.

Re-enable the trigger manually after fixing the underlying cause. Google's automatic disable doesn't self-heal once the root cause is fixed — the trigger needs to be manually re-created or re-enabled in the Apps Script editor's Triggers panel after you've addressed whichever of the three causes applied.

Things to Consider

• This is a different failure mode from a duplicate or repeated run. See what do you do when an automation runs twice or sends duplicates for a trigger firing too often; this page covers the opposite direction — a trigger that has stopped firing at all.
• The same category of platform-enforced limits and silent-failure risk exists on other platforms too. See why was your Power Automate flow suspended or throttled for Microsoft 365's equivalent quota and inactivity mechanisms, and how do you stop an automation from failing silently for the general principle of building your own alerting rather than trusting a platform to always tell you when something breaks.
• A script tied to one person's personal Google account is a single point of failure for a business process. If the script matters operationally, consider whether it should be owned by a shared or admin-managed account rather than an individual employee's, precisely so authorization doesn't lapse when that person's account status changes.
• Growing data volume is a predictable, not sudden, cause. A script approaching its execution-time or daily-quota limit usually shows warning signs (slower runs, occasional near-miss timeouts) before it fully breaks — checking the Executions log periodically, not just after something visibly stops, catches this before it becomes an outage.
• A silently stopped trigger is especially easy to miss when it's the thing responsible for alerting someone else. If the broken script is what posts notifications into Google Chat, nobody gets told the automation stopped — build a separate, independent check for scripts that are themselves your alerting mechanism.

Common Mistakes

• Assuming the script's code broke and rewriting logic that was never the problem. In most cases the script's own logic is fine; a quota limit, an unhandled dependency error, or a revoked authorization is the actual cause, not a flaw in what the script does when it runs successfully.
• Not checking the Executions log first and guessing instead. The log almost always states the actual error directly — skipping it in favor of guessing wastes time on the wrong fix.
• Re-enabling a disabled trigger without fixing the underlying error. If the same unhandled error caused the original failures, simply turning the trigger back on reproduces the same repeated-failure pattern and Google disables it again.
• Leaving a business-critical script authorized under one employee's personal account indefinitely. This creates exactly the single-point-of-failure risk that causes a script to break the moment that person's account changes or they leave the company.
• Ignoring Google's own notification email about the disable. The explanation for why a trigger was disabled is often sent automatically and then overlooked, leading to unnecessary time spent re-diagnosing something Google already explained.