Google Apps Script is a powerful way to automate tasks across Google Workspace and Google Drive, but it comes with strict limits that can really trip you up as you build automated solutions. This guide introduces the key quotas, limitations, and constraints you should understand before relying on Apps Script for larger automations.
If your team is on Google Workspace, chances are you’ve encountered Google Apps Scripts (GAS) - a simple yet powerful way to build automation directly into your Google ecosystem, powering up Google Sheets, Drive, Gmail, and more. With a bit of developer know-how (or some elbow grease), you can build useful and versatile automations for your business.
However, like many automation tools, the sky is not the limit, and you should be aware of the most important limitations you will face when building Apps Scripts. Apps Scripts are subject to hard limits and quotas, which are crucial to understand when building bulk automation solutions like mass folder and file copying or bulk folder operations.
In this guide, we’ll go through these limitations as of 2026, strategies to work around them, and why it may just be simpler to use a 3rd party solution like FolderPal to handle your Drive automation tasks instead.
There are a bunch of Apps Scripts quotas and limits that Google imposes, and depending on whether you have a Consumer account or Workspace account, could be a huge pain down the track. Below are the most common limits faced and how they work.
Google Apps Scripts run in a synchronous execution model by nature, meaning each script executes step-by-step within a single thread. You typically would need to wait for each request to complete first before making the next one.
This design simplifies simple automations, but limits parallelism, throughput, and execution time, making Apps Script unsuitable for high-concurrency or long-running workloads.
Google Apps Scripts run in a stateless execution environment. Each invocation starts fresh, with no guaranteed memory or persistence between runs.
For any long-running operation or task that requires memory between different Script runs, there is no native method to store state, which presents problems with error recovery, retries, resuming jobs, and handling high volume tasks.
Google Apps Scripts have a 6 minute total execution runtime limit. For your long-running tasks like file uploads, folder tree recursion, and bulk Drive API tasks, once 6 minutes is reached (on both Consumer and Workspace accounts), the run is aborted and an “Exceeded maximum execution time” exception is thrown.
When any limit is reached, all Google Apps Scripts execution halts, throwing exceptions like “Limit exceeded: Properties read/write”, “Service invoked too many times: Drive”, “Exceeded maximum execution time”. Limits only refresh 24 hours after the very first request.
Apps Scripts have a huge list of daily quotas which are exhaustively long. It is recommended you refer to this quota page for the specific operations you want to carry out.
Apps Scripts out-of-the-box supports some limited idea of concurrent script processing, though it is relatively brittle. The limits include:
For more complicated long-running tasks like folder tree operations and bulk copying, these limits on Scripts may not be suitable.
Beyond Apps Scripts quotas, the specific Google service you are calling, such as Drive API, would impose their own usage limits for your Workspace. Without a good understanding of these underlying service limits, building Apps Scripts on top of them could lead to significant headaches with broken runs and brittle automations.
If you are set in stone on solving your problem with Google Apps Scripts, then you may still be able to build around long-running tasks and concurrent executions with these strategies. However, note that they all have tradeoffs.
For massive jobs like processing thousands to millions of rows in Google Sheets, or performing major bulk operations on Google Drive folder trees, you can split your job into chunks of work. At a high level, the steps are:
This approach is not foolproof, as executions are still bound by restrictive quotas like daily trigger-based execution time limit, Properties daily quotas and total storage, etc.
Whatever tasks you are automating, storing progress checkpoints between script executions is critical. The simplest approach is using the PropertiesService Class, which lets you store simple key-value pair data scoped to a single script. You would simply use setProperty() and getProperty() to persist state across execution contexts.
For example, you may want to store the last row successfully processed to know where to resume, or the last created folder’s ID to keep track of where in the folder tree you are up to.
For some use cases, you may even want to use a hidden Google Sheet for more complex state management, though this would be subject to Google Sheets API quotas.
The major drawback of tracking state natively with Google Apps Scripts is the very limited quotas you get. If you expect the script to be running constantly, you may encounter quota limits very quickly.
Google Apps Scripts allows time-driven triggers to be called programmatically. This means from within a script execution, you can run the same script at a later point in time. This is known as trigger chaining and can be a simple but effective method to picking up jobs from where they left off.
A standard best practice when writing Google Apps Scripts is to take advantage of fetchAll() when making HTTP requests. Multiple requests can be made at the same time, significantly reducing wall-clock time as you only need to wait for the longest-running request to complete, rather than making sequential calls.
However, you’re still subjected to a 20,000 daily requests limit (100,000 on Workspace) made via URL fetch, which counts each individual HTTP request. You’re also not free from Service Quotas - if you make 50 requests to Drive, that counts as 50 calls against the Drive limits.
When writing Google Apps Scripts with services that specify a throughput limit (e.g. n calls per second), making requests like a firehose would quickly get your API usage flagged and rate limited, running into errors like “Service invoked too many times in a short time”.
Some simple industry best-practices are to implement:
Your script would require using the Utilities.sleep() method to ensure the script is not biting off more than it is allowed to chew.
Some users work around quotas by rotating tasks across multiple Google accounts. This is generally not reliable for long-term automation due to credential management, security risk, and compliance issues. But if you have the time and patience, it may be a path forward.
Apps Script is excellent for small, simple automations, like sending a few emails, light data manipulation, and small file moves. However, it was never designed to support large-scale, long-running workflows.
When you’re trying to clone folders and files in bulk, or performing large-scale edits across Drive, you’ll likely bump into limits or quotas that will quickly hamper your productivity.
If you’re building Google Drive automations and keep running into these walls, choose FolderPal.
FolderPal helps you perform bulk folder and file operations without the headache. With FolderPal you get:
Instead of bashing your head against Apps Script limitations just to achieve some basic automations, FolderPal manages all of this behind the scenes.
Try FolderPal today.