Bulk Google Drive folder copying often fails due to API rate limits, write quotas, and Apps Script timeouts. This guide explains the real Drive API limits, common 403 and 429 errors, and how to automate folder and file operations reliably at scale, or let FolderPal handle it for you.
Working with long-running bulk operations in Google Drive can be complicated. From duplicating large nested folder structures, uploading large files, or rolling your own bulk permissions operations, you’ll eventually encounter a minefield of API limits in your script or automation. This causes a bunch of problems like stalled or broken scripts and unpredictable failures.
FolderPal’s job queue under the hood deals with all of these Drive API limits for you. However if you’d like to build it yourself, this guide summarizes all the up-to-date Google Drive API limits based on official documentation and sources.
Google Drive API limits are many, and the workarounds are just as numerous (and messy). Whether you’re a freelancer writing Google Apps Scripts or a developer integrating directly with the API, knowing all the limits you’ll encounter will give you the knowledge to build resilient solutions.
When working with Google Workspace and Google Drive, the points below summarizes the most common limits you’ll encounter:
These limits apply regardless of whether operations are triggered via Apps Script, the Google Drive UI, or the Drive API.
Google Drive implements relatively generous but strict volume-based limits across users’ workspaces and Drives.
For agencies and teams dealing with large files, a single user or service account can transfer a maximum of 750 GB of data within a rolling 24-hour window. This limit includes both file upload and file copy operations. For files larger than 750 GB, the transfer will crash mid-processing when it reaches the transfer limit.
Both My Drive and Shared Drive have a 500,000 total item limit, which includes files, folders, shortcuts, and items in the trash. Exceeding this limit will set Google Drive to read-only, preventing further operations. Make sure you are emptying the trash to free up item quotas.
All Apps Scripts are subject to a hard 6-minute execution timeout, after which the script crashes. There is a further daily cumulative execution limit (90 minutes on Standard accounts, 6 hours on Google Workspace accounts) applying to all Apps Scripts initiated from triggers. If your total script runtime for the day exceeds these limits, you’ll run into an “Exceeded maximum execution time” error and will have to wait for the daily reset (midnight Pacific Time).
For bulk tasks, this is relatively limiting, considering that Apps Scripts are single-threaded and don’t support true parallel processing, meaning tasks must complete one-by-one. You’ll quickly find that bulk folder and file operations built using Apps Scripts are very brittle and often miss items, or take a very long time to finish.
However, there are useful strategies to work around these limits, by simulating long-running jobs and mimicking parallel script executions.
Google Drive’s most notorious API limits are rate limiting and throttling quotas on read/write operations, usually triggering the infamous 403: User Rate Limit Exceeded and 429: Too Many Requests error codes.
Across a Google Workspace project, a total of 12,000 requests are allowed in a 60 second window by default (as of 2022). This limit applies to all read and write requests from users, whether via the UI or API. This is roughly 200 requests per second, which would typically be enough for most use cases.
A higher project quota can be requested in Google Cloud Console for high-traffic applications, though approval may still need to be granted.
Within a workspace, a single user by default can make 2,400 requests every 60 seconds. This can be adjusted as an admin in Google Cloud Console, up to the project quota.
Although not an officially documented limit, Google has given general guidance of 3 write operations per second sustained over a period of time when using the Google Drive API.
This limit includes both copy and create operations, and applies to both folder and file writes. Write requests are counted towards the limit from when they are first initiated, so throughput management is required.
There is no official documentation from Google on how this limit is enforced, however based on community testing, it’s likely there is a token bucket limiter controlling the allowance behind the scenes. You’ll likely be allowed to do up to a burst of ~30 write requests before being limited to 1 token refresh per second.
Depending on what you’re building, there are several best practices to adopt when building scripts or automations with the Google Drive API.
Whether script or custom code, adopting an exponential backoff strategy when encountering a 403 or 429 rate limit error code would be the simplest solution. This would involve waiting (or sleeping) execution for a period of time on encountering these errors, with exponentially increasing delays (1s, 2s, 4s, 8s) on successive limit hits before resuming the next operation.
However, hitting the Drive API limits directly too frequently may impose further restrictions and flag your account, forcing unpredictable delays. Controlling throughput via throttling is a better strategy.
Rate limiting controls the rate at which you make requests. In the case of write operations, adding a small sleep delay between requests ensures you aren’t making bursts of requests that will quickly exhaust your limit. This way, you can control and throttle your own request rate without hitting the Drive API limits directly.
However, with Google Apps Scripts, requests are made synchronously, so you’ll have to wait for each request to complete before issuing the next one. The fetchAll() method lets you run batches of requests, though you’d have to wait for the whole batch to complete first. This makes throttling unreliable as requests can take under 100ms to an average of several hundred ms.
If you are building a custom-coded solution, you may have the luxury of parallel processing. In that case, it would still be recommended you throttle requests using a delay, or even your own token bucket algorithm to manage throughput.
A more resilient architecture is usually needed for frequent, long-running tasks. For those with more demanding needs, the most popular approaches include a message queue system with background workers that can work in parallel, for example RabbitMQ, Amazon SQS, and Google Cloud Pub/Sub. This lets you orchestrate jobs asynchronously without needing to wait for execution to complete.
Along with a message queue, you’d need a way to manage usage limits for your workspace to make sure you aren’t creating too many requests at once, or respecting daily quotas. Typically a caching service like Redis is used to track throttling and usage between jobs.
This approach allows thousands of Drive operations to run safely over hours instead of failing after minutes.
In Google Drive, you can perform Batch Requests, which combine a bunch of API calls (up to 100) into one network request. However, each individual API call still counts towards your limits. The main benefit of batching is making only one network roundtrip instead of a hundred.
Above all, measuring your Workspace API usage gives you the insight to track and escalate API usage issues. With a combination of the Google Cloud Console’s API Dashboard and usage-based alerts, you can figure out how much of your API quotas are being consumed, and how often you are hitting limits.
Community users have experimented with Google Apps Scripts to run longer than 6 minutes through pathways that some consider to be unnatural. These workarounds are not foolproof, but certain strategies might allow you to simulate long-running Google Apps Scripts execution beyond the 6 minute execution limit.
Google Apps Scripts are generally reserved for simpler operations. Heavyweight operations that run into the hundreds and thousands of operations might call for custom solutions. However if you’re still committed to Google Apps Scripts, there are strategies to simulate parallelism in Google Apps Scripts.
FolderPal handles all of these Drive limits intelligently behind-the-scenes. When duplicating nested folder trees and copying files, FolderPal’s job queue system considers all of Google Drive’s limitations to ensure your operations work reliably.
In-built FolderPal behaviour includes:
Before you start hacking away at a custom solution that could be incredibly time-consuming and costly, try FolderPal for free so you can start copying Drive folders seamlessly.