I’ve been running a Google Apps Script for a long time without issues, and there haven’t been any recent changes to the code. However, lately I’ve been frequently encountering this error:
Exception: Service error: Drive
at ******(****:14:25)
at ******(******:99:9)
at *****(*****:17:9)
The script structure is still solid, and it usually works again if I rerun it, but the error keeps appearing intermittently.
Has anyone experienced this issue before? What could be the root cause, and is there a way to resolve it permanently instead of relying on reruns?
Hi, we are experiencing the same instability. We’re seeing Exception: Service error: Drive specifically when calling DriveApp.getFileById(). The script has been running for a long time without changes, and the error seems intermittent as it eventually works after a few retries.
Hello, i have been exeriencing exaxtly the same instability since yerstarday. I use these scripts for over a year now with no problem. Eventually they work after several retries.
Im having the same issue, have a few scripts that I run every day that download attachments from emails and move the files into google drive folders. Running for almost 2 years without an issue and now constant drive errors, ended up having to change every script to rerun 5x everytime theres a drive error just to get them to finish but now they all take twice as long to run because of the constant drive errors
Getting the same issue with scripts that have not had issues before when trying to call DriveApp and manipulate DriveApp objects.
Sorry nothing useful to add, but we’re getting the same. I’m going to refactor using the REST API to avoid getFileById(), but it’s a needless pain. It’s been raised on the issue tracker here and here
Hello, same problem here mainly withgetFolderById on a code that was running smothly just the week before without change.
Adding our production experience to confirm this is widespread:
We’re running a Google Apps Script library deployed across 10+ Google Sheets installations (Spain, social services sector). We’ve been hit hard since around last Friday with intermittent failures across multiple DriveApp methods:
-
DriveApp.getFolderById() — fails sporadically even with valid IDs
-
DriveApp.getFileById() — same pattern
-
folder.getFiles() / folder.getFolders() iterations — fail mid-iteration with “Service error: Drive”
-
file.makeCopy() — frequent failures during template copying
Patterns observed:
-
Errors come in clusters (30–60 second windows where everything fails, then back to normal)
-
Multiple accounts and multiple shared drives affected independently
-
A single retry usually succeeds, but during sustained episodes even 5 retries with exponential backoff (2s/5s/10s/20s) can fail
-
Worst symptom: when getFolders() throws mid-iteration, a try/catch can absorb the error as “folder not found”, leading scripts to incorrectly create duplicate folders. We’ve seen this in production today.
Mitigations deployed in our codebase today:
-
Wrap every DriveApp call in retry helpers
-
Retry the search phase (not just creation) before falling through to createFolder()
-
Decouple side-effect operations so partial failures don’t abort entire batches
The Workspace Status Dashboard still shows everything as “Available”, but the production impact is real and ongoing. Would appreciate official acknowledgment.
Region: Europe (Spain). Workspace business account.
I confirm the experiences reported by
aforcade_formacion
It is unexpected that GOOGLE has this type of failures!
Please fix it because this retry strategy is a waste even if it seems the only way out today!
It seems to me that they tweaked down the computation capability of their clusters running these jobs but forgot to give more slack for the errors timeouts … (really just a very wild guess).
It is important that google officials explain what is going on here because the effect is devastating
I am experiencing the same issue. Scripts I have been using for years are suddenly failing with “Exception: Service error: Drive”. The first time I saw this was yesterday, April 27, 2026. These scripts are essential to my daily work, and if they stay broken like this it will be devastating.
Currently if I run the script once it completely fails. If I run it a second time it halfway works before failing, and I can manually do the last half of what it was meant to do.
Need a fix for this!
After much frustration, I have been using the following AI prompt to rewrite chunks of code.
TECHNICAL ARCHITECTURE & RESILIENCE REFERENCE (TARR)
System Standards for High-Volume Drive Metadata Operations
1. THE CORE UTILITY: SAFEDRIVECALL
This helper is the mandatory engine for all Drive API interactions. It prevents crashes by handling handshake failures via exponential backoff.
JavaScript
/**
* THE GUARD: Standardized API Wrapper
*/
function safeDriveCall(operation, retries = 5) {
let attempt = 0;
while (attempt < retries) {
try {
Utilities.sleep(500); // Baseline Heartbeat: Prevents rapid-fire congestion
return operation();
} catch (e) {
attempt++;
if (attempt >= retries) throw e;
const waitTime = attempt \* 4000;
Logger.log("⚠️ API Congestion. Backing off " + (waitTime/1000) + "s...");
Utilities.sleep(waitTime);
}
}
}
2. THE IMPLEMENTATION PATTERN: “GATHER → GAP → WRAP → SYNC”
Every folder-creation function must follow this four-phase structure to neutralize the Accumulated Error condition.
PHASE 1: THE MANIFEST (DATA GATHERING)
Collect all external data (Properties, Session info, Spreadsheet values) into a local JavaScript object before performing any Drive operations.
- Purpose: Minimizes the time spent holding open Spreadsheet and Property service handles.
PHASE 2: THE AIR-GAP (SESSION RESET)
Execute SpreadsheetApp.flush() followed by a 3-second Utilities.sleep(3000).
- Purpose: Forces the Google backend to “reset” the execution token and clear metadata debt from the gathering phase.
PHASE 3: WRAPPED EXECUTION & PACING (THE WORK)
Execute all Drive operations using the safeDriveCall wrapper. Divide the work into logical “Execution Blocks.”
-
Sync Points: Insert a 5-to-8 second Utilities.sleep() between high-density blocks (e.g., after creating a primary folder set or a large file-copy loop).
-
Purpose: Allows the Drive Indexer to “drain” the backlog between bursts.
PHASE 4: PARITY WRITE-BACK (THE COMMIT)
Perform final Spreadsheet updates using only the data stored in the Phase 1 Manifest. Use LockService to protect the write-back.
3. VERIFICATION & DEPLOYMENT STANDARDS
-
Staging: New logic must pass a “10-Run Stress Test” (consecutive executions) in a test environment to confirm the pacing is sufficient for current server latency.
-
Parity: The “Safety Overlay” must never change the original functional intent (IDs, naming, or column mapping); it only modifies the timing and reliability of the execution.
I have returned just to say that this issue did clear up for me the day after I posted here. I never learned why the issue occurred, or what the fix was. I am glad it’s over though. Thank you to whoever fixed it. 