Even the most experienced developer rarely writes code correctly on the first try, making troubleshooting an important part of of the development process. In this section we'll cover some techniques that can help you find, understand, and debug errors in your scripts.

Error messages

When working in the Script Editor, you'll see an error message appear as soon as your script encounters a problem. They are displayed in a red bar at the top of the screen and often the line that contains the error is highlighted. There are two basic types of errors displayed in this way: syntax errors and runtime errors.

Syntax errors

These are caused by writing code that doesn't follow the JavaScript grammar, and the errors are detected as soon as you try to save the script. Take for example the following code:

function emailStockPrice() {
  var info = FinanceApp.getStockInfo('.DJI');
  var price = info['price';
                    'Dow Jones Industrial Average',

Do you see the problem? There is a missing ] character at the end of the third line. When you try to save the script you'll get the following error:

Missing ] in index expression. (line 3)

These types of errors are usually simple to troubleshoot, since they are found right away and typically have simple causes. You aren't able to save a file that contains syntax errors, meaning that only valid code is saved into your project.

Runtime errors

These errors are caused by using a function or class incorrectly, and can only be detected once the script has been run. Take for example the following code:

function emailStockPrice() {
  var info = FinanceApp.getStockInfo('.DJI');
  var price = info['price'];
                    'Dow Jones Industrial Average',

The code is formatted correctly, but we are passing the value "john" for the email address when calling MailApp.sendEmail. Since this is not a valid email address the following error will be thrown when running the script:

Invalid email: john (line 4)

What makes these errors more challenging to troubleshoot is that often the data you are passing into a function is not written in the code, but instead pulled from a spreadsheet, form, or other external data source. Using the debugging techniques below can help you to identify the cause of these errors.


Not all mistakes cause an error message to be displayed. There might be a more subtle error where the code is technically correct and can execute, but the results are not what you expect. Here are some strategies for handling such situations and further investigating a script that is not running the way you expect.

Execution transcript

Every time you run a script, Google Apps Script records an execution transcript, which is a record of each call to a Google Apps Script service that is made while the script runs. These transcripts can help you to understand which actions your script performed. To view the execution transcript click on View > Execution transcript in the menu bar after the script finishes running.

For example, if you run the emailStockPrice script above using the email address "" and then view the execution transcript you should see output like:

[13-04-10 12:33:27:646 PDT] FinanceApp.getStockInfo([.DJI]) [0.071 seconds]
[13-04-10 12:33:27:687 PDT] MailApp.sendEmail([, Dow Jones Industrial Average, 14811.2802734375]) [0.04 seconds]

If you run that script with an invalid email, such as "john", then the transcript will look like:

[13-04-10 12:33:27:646 PDT] FinanceApp.getStockInfo([.DJI]) [0.071 seconds]

This tells you that the last method to execute correctly was FinanceApp.getStockInfo, so the error must be after that method in the script. The execution transcript is reset each time the script is run.

Logging custom messages

The execution transcript only records calls to Google Apps Script services, but it can be useful when troubleshooting to record other data as well. Google Apps Script enables you to write custom messages to a log file, which can be viewed after the script has completed. To write these messages call the log method of the Logger class passing in the data you want to record. After the script has run you can view all the messages that were logged by clicking View > Logs in the menu bar.

Consider this more advanced version of the emailStockPrice script:

function emailStockPrice(symbol, email) {
  Logger.log('Emailing stock price of ' + symbol + ' to ' + email);
  var info = FinanceApp.getStockInfo(symbol);
  var price = info['price'];
                    'Price for: ' + symbol,

When this script is run on the inputs ".DJI" and "" the following logs are written:

[13-04-10 12:35:56:636 PDT] Emailing stock price of .DJI to
[13-04-10 12:35:56:679 PDT] {priceopen=14673.46, symbol=.DJI, change=139.95996, ...}

The method Logger.log expects a string value, but if you pass in an object or array it will do its best to convert that into a string. The logs can only hold a limited amount of data, so avoid logging large amounts of text. The logs are reset each time that the script is run, so if you wish to preserve the output you can use the method Logger.getLog to retrieve the current log file, which you can then send out in an email, store in a spreadsheet, etc.

Using the debugger and breakpoints

The Script Editor lets you run a script in debug mode, which is specifically designed for locating problems. When run in debug mode a script will pause when it hits a breakpoint, which is a line you've highlighted in your script that you think may have a problem. When a script pauses it will display the value of each variable at that point in time, allowing you to inspect the inner workings of a script without having to add a lot of logging statements.

To add a breakpoint click on the line number for the line you want to pause at.

Setting a breakpoint

To run the script in debug mode click the bug icon (Bug icon) in the toolbar. Before the script runs the line with the breakpoint it will pause and display a table of debug information.

Pausing at a breakpoint

This table allows you to inspect the values of the parameters like symbol and email, as well as the stock info results stored in the info object. Notice that the price variable doesn't have a value assigned yet, because the script paused before that line was executed.

When the script is paused, an extra set of buttons are displayed in the toolbar which allow you to control how the script is run. Using the "step in", "step over", and "step out" buttons you can run the script one line at a time, allowing you to inspect how values change over time.

Common errors

Service invoked too many times: \<action name>
This error indicates that you have exceeded your daily quota for a given action. For example, you might encounter this error if you send too many emails in a single day. The quotas are set at different levels for consumer, domain, and premier accounts and are subject to change at any time without a prior announcement by Google. You can view the quota limits for various actions on the Google Apps Script Dashboard.

Server not available.
Server error occurred, please try again.
There are a couple possible causes for this error:

  • A Google server or system is temporarily unavailable. Wait for a few moments and try running the script again.
  • There is an error in your script that doesn't have a corresponding error message. Try debugging your script and see if you can isolate the problem.
  • There is a bug in Google Apps Script that is causing this error. Report the error on the issue tracker.

Authorization is required to perform that action.
This error indicates that the script is lacking the authorization needed to run. When a script is run in the Script Editor or from a custom menu item an authorization dialog is presented to the user. However, when a script is run as a service, embedded with a Google Sites page, or run from a trigger the dialog cannot be presented and this error is shown. To authorize the script, open the Script Editor and run any function. To avoid this error, remember to run the script once in the Script Editor after adding new services or capabilities to your script.

Access denied: DriveApp
The domain policy has disabled third-party Drive apps
Administrators of Google Apps domains have the ability to disable the Drive SDK for their domain, which prevents their users from installing and using Google Drive apps. This setting will also prevent the users from being able to use Apps Script add-ons that use the Drive service or Advanced Drive Service (even if the scrupt was authorized prior to the admin disabling Drive SDK).

However, if an add-on or web app using the Drive service is published for domain-wide installation and is installed by the administrator for some or all users in the domain, the script will function for those users even if the Drive SDK is disabled in the domain.

Getting help

Debugging a problem using the tools and techniques listed above can solve a variety of problems, but there may be issues you run into that require some extra help to solve. See our Support page for information on where to ask questions and file bugs.

Send feedback about...

Apps Script
Apps Script