Google Sheets Apps Script Not Working? Fixes to Try

If Apps Script is not working in Google Sheets, first check whether the script is attached to the right spreadsheet, then open the Apps Script editor and inspect the latest execution for an error message. Most failures come from a code or sheet-name mismatch, missing authorization, a trigger that did not run, or a limit on what the script is allowed to do.

Identify where the failure occurs

“Not working” can describe several different problems: a script may not appear in the spreadsheet, may fail when you click Run, may run without changing the sheet, or may work manually but not automatically. Pin down which behavior you see before editing code. The location and timing of the failure often point to the cause.

The script is missing: check whether you opened the intended spreadsheet and whether its script is bound to that file.
Run produces an error: read the error and the line number in the Apps Script editor.
There is no visible result: verify the destination tab, cell range, and whether the code actually reaches the write operation.
It works manually but not on its own: investigate the trigger type, trigger setup, and the account that created it.

In Google Sheets in a browser, open a bound script from Extensions > Apps Script. A script opened from the Apps Script home page may instead be a standalone project, not attached to the spreadsheet you are viewing. That difference matters: a bound script can use the active spreadsheet in many contexts, while a standalone script generally needs code that explicitly opens the target spreadsheet.

Check the project, file, and sheet names

A script can run successfully against the wrong file or fail because a tab name in the code no longer matches the sheet. Check the spreadsheet title and the tab labels carefully, including spaces and punctuation. For example, a tab named “Q1 Data” is different from “Q1 data” if your code is looking up a sheet by its exact name. Renaming a tab without updating a hard-coded name can break a script that previously worked.

Also look at how the code selects its spreadsheet and sheet. A function that uses the active spreadsheet may behave differently when run from a standalone project or an automated trigger than when run directly from a bound project. For a bound script, confirm that the project was opened through the spreadsheet you intend to edit. If it is standalone, verify that its code identifies the correct spreadsheet rather than assuming that the currently open browser tab is the target.

Before troubleshooting a large script, test a small, reversible action in the intended file—for example, writing a temporary value to a known empty cell, then removing it. If the test writes to the expected tab, the connection is working and the problem is more likely in the original code’s conditions, ranges, or data assumptions.

Read the error and execution details

In the Apps Script editor, select the function you want to run and click Run. The first run may prompt you to authorize the script. After it runs or fails, inspect the execution details; the editor also provides an Executions view in its left-hand navigation, where you can review recent runs and their status. An error message and line number are more useful than repeatedly clicking Run without changing anything.

Common messages provide clues. “Cannot read properties of null” can mean the script did not find a sheet, range, or other object it expected. A permission or authorization error points to an account or access issue. A timeout or quota-related failure suggests the script is doing too much, running too often, or reaching a service limit. Read the full message and the surrounding code: the reported line may be where a bad value was used, not where it originated.

Add temporary logging where it can clarify assumptions, such as the name of the selected sheet or the number of rows being processed. In Apps Script, the execution details can include logs from calls such as Logger.log(). Remove or reduce noisy diagnostic logging once the cause is known, especially if a recurring trigger could generate a large volume of logs.

Fix common code and range problems

Small changes in a spreadsheet can invalidate assumptions in a script. A range may have fewer rows than expected, a row may be blank, or data may contain text where the code expects a number or date. Check how the script handles empty cells and unexpected values before assuming that a Sheets service is broken. A loop that works on a full table may also fail when it tries to read past the last populated row.

Look for hard-coded row numbers, column numbers, and tab names. If a header row is inserted, a script that assumes records begin on row 2 may now read the wrong cells. If users add columns, fixed column positions can point to different information. Where appropriate, use a clearly defined range based on the current data size, and verify that its dimensions match the values the code reads or writes.

When the script writes data, confirm that the destination range has the same number of rows and columns as the values being written. Also check whether a protected range, filter, or merged cells affect the intended destination. If the sheet contains formulas, make sure the script is not overwriting them unintentionally. Try the smallest possible test case first, then restore the full data range after the logic is verified.

Understand triggers and automatic runs

Triggers are a frequent source of confusion because a function that works with the Run button may not behave the same way when it runs automatically. A simple trigger, such as a function named onEdit(e), runs in response to certain user actions. It is not a general-purpose timer, and it does not run in response to every change: edits made by another script or an API do not cause an edit trigger to fire. A simple trigger also has restrictions, including limits on authorization-dependent services and execution time.

If a task needs broader permissions or a schedule, create an installable trigger from the Apps Script editor’s Triggers section. Choose the function and event type carefully—for example, a time-driven trigger for scheduled work or a spreadsheet event for an appropriate sheet action. An installable trigger runs under the account of the person who created it, so that account must retain access to the spreadsheet and any other services the script uses.

Check the trigger list for duplicates, the wrong function, or an event type that does not match the intended action. A trigger failure may appear in the execution history even when no one saw a pop-up in the spreadsheet. For an edit handler, remember that the event object is supplied by the trigger; clicking Run manually does not provide the same event data. A handler that expects an event object can therefore fail during a manual test unless it is written to handle that case.

Review authorization and sharing access

Apps Script may ask an account to grant access before code can use Sheets or other Google services. If the authorization flow was dismissed, if the script’s requested access changed, or if a different account is running the code, the script may stop at an access error. Run the function manually from the editor while signed in to the account that should run it, then follow the authorization prompts if they appear. Only approve access for a script you trust and understand.

Being able to open a spreadsheet does not guarantee that every script action is allowed. The running account may lack edit access, may not have access to a referenced file, or may be restricted by a Google Workspace administrator. Organization policies can limit Apps Script services or access to external services. If a script used to work and then stopped after an account, sharing, or administrator-policy change, ask the file owner or Workspace administrator to check access rather than trying to bypass the restriction.

Sharing a spreadsheet does not necessarily mean every collaborator can authorize or manage its automation in the same way. Confirm who owns the script project, who created any installable triggers, and which account is expected to execute the task. This is especially important for recurring work: a trigger tied to a departing employee’s account may stop being dependable when that account loses access.

Custom functions have special limits

A custom function is a user-defined function entered into a spreadsheet cell, much like a built-in Sheets formula. It is useful for calculations based on the function’s inputs, but it is not a substitute for every script action. Custom functions cannot freely edit arbitrary cells, and they have restrictions on services that require user authorization. They also need to return a value to the cell that called them; code that only changes a different cell will not work as a cell formula.

Custom functions may recalculate when their referenced inputs change, but they are not a reliable way to react to every spreadsheet event or to perform scheduled updates. If you need to send email, update unrelated cells, or run a job on a schedule, use an appropriate menu action or installable trigger instead, subject to authorization and service restrictions. If a custom function returns an error, check its input types and returned value as well as its execution details.

Keep the platform distinction clear: Google Sheets Apps Script is JavaScript-based automation for Google Workspace. It is not Excel VBA, and Apps Script menu names and triggers do not apply to Microsoft Excel. Excel has its own automation options, such as Office Scripts and VBA, with different capabilities and setup.

Reduce timeouts and avoid unreliable designs

A script that processes many cells one at a time can be slow and may run into execution limits. A common improvement is to read a whole range into an array, process the values in memory, and write the results back in a batch rather than making a separate spreadsheet-service call for every cell. Keep the selected range as small as the task allows, and avoid repeatedly reading the same data inside a loop.

Also consider whether a trigger is firing more often than necessary. An edit handler that scans an entire workbook after every small change can become slow and create unnecessary work. Restrict its response to the relevant sheet, column, or range, and make sure it does not recursively cause the same action it is meant to handle. If a task must handle a large dataset, split it into manageable work or redesign the process rather than relying on repeated manual retries.

Frequently Asked Questions

Why does my Apps Script work when I click Run but not when I edit a cell?
Manual runs and edit triggers are different execution contexts. Confirm that the function is connected to the intended trigger, that the edit is one that triggers it, and that the code handles the event object. Changes made by another script or through an API do not fire a simple edit trigger.

Why does Google Sheets say I need to authorize the script?
The function may be requesting access to a Google service, or you may be running it from a different account. Run it from the Apps Script editor while signed into the intended account and review the requested permissions before granting them. Workspace administrator policies can also affect access.

Why is my script not finding a sheet?
Check that the script is attached to or explicitly opening the correct spreadsheet, then compare the tab name in the code with the actual name, including spaces and capitalization. A renamed tab or a standalone script that assumes an active spreadsheet can lead to a missing-sheet result.

Can an onEdit function run a script automatically every day?
No. An edit trigger responds to qualifying spreadsheet edits, not a daily schedule. Use a time-driven installable trigger for scheduled execution, and ensure that the account creating it has the access the script needs.

Where can I see why an Apps Script run failed?
Open the Apps Script project and check Executions in the left navigation. Select the relevant run to inspect its status and error details. The editor’s execution information and any logs can help identify the failing line or assumption.

Try it: the Formula Explainer: paste any formula and see each function and reference in plain English.

More in Errors & fixes

Sources: Function behaviour and menu paths: Microsoft Support documentation for Excel. Method & sources

Spotted an error in this guide? Let us know.