# Firestore: “4 DEADLINE_EXCEEDED: Deadline exceeded”
> Firestore returns 4 DEADLINE_EXCEEDED when a read or write takes longer than its deadline. Causes: large reads, hot spots, sudden traffic, and each fix.
Canonical: https://app369.com/fix/firestore-deadline-exceeded/
Last updated: 2026-11-08
A query, batch or Cloud Function fails with Error: 4 DEADLINE_EXCEEDED (deadline-exceeded in the client SDKs). Firestore ran out of time before the operation finished. The usual reasons are a read that returns too many documents at once, writes piled onto a narrow range of documents, or traffic that jumped faster than Firestore could scale.
**Short answer**
Find which operation timed out and how big it is. Split large reads with limit() and query cursors, and split big writes into smaller batches. If many writes go to documents with sequential IDs or a timestamp-ordered range, spread them out with auto-generated IDs. Ramp new traffic up gradually. Retry with backoff, but only writes that are safe to repeat, because a write that timed out may still have been applied.
## **Why Firestore timed out, and the fix**
1. 01 ### **A read that returns too many documents**
> “Use pagination to split large reads.” [**Google Cloud, Resolve latency issues**](https://cloud.google.com/firestore/docs/resolve-latency) A get() on a whole collection, or an export script that reads everything in one call, can run past the deadline as the data grows. Read in pages with limit() and startAfter(), and process each page before asking for the next.```
let last = null;
do {
let q = db.collection('orders').orderBy('createdAt').limit(500);
if (last) q = q.startAfter(last);
const page = await q.get();
// process page.docs here
last = page.docs[page.docs.length - 1] ?? null;
} while (last);
```
2. 02 ### **Writes piled onto a narrow range of documents**
> “Hot-spots (high read, write, and delete rates to a narrow document range) limit the ability of Firestore to scale.” [**Google Cloud, Resolve latency issues**](https://cloud.google.com/firestore/docs/resolve-latency) Document IDs that count up (order-0001, order-0002) or start with a timestamp send every new write to the same spot in Firestore’s key range, and an indexed timestamp field does the same to its index. At high write rates that becomes a hot spot. Use auto-generated IDs from add() or doc(), and keep a high write rate off a single document such as a global counter.
3. 03 ### **Traffic that jumped all at once**
> “We recommend starting with a maximum of 500 operations per second to a new collection and then increasing traffic by 50% every 5 minutes.” [**Firebase, Best practices for Cloud Firestore**](https://firebase.google.com/docs/firestore/best-practices) A launch, a migration or a backfill that sends full traffic to a new collection at once can time out while Firestore scales up. Start slower and increase step by step, and run backfills with a rate limit instead of as fast as the script can go.
4. 04 ### **Retrying a write that may have worked**
> “For operations that change the state of the system, this error may be returned even if the operation has completed successfully.” [**gRPC, Status codes and their use in gRPC**](https://grpc.io/docs/guides/status-codes/) DEADLINE_EXCEEDED doesn’t prove the write failed. Retry with exponential backoff, but make the write safe to repeat first: set() with a known document ID, or a transaction that checks before it changes, so a retry doesn’t double charge or duplicate an order.
Checked against the vendor’s docs on November 8, 2026: [Google Cloud: Firestore error codes (DEADLINE_EXCEEDED)](https://cloud.google.com/firestore/docs/understand-error-codes); [Google Cloud: Resolve Firestore latency issues](https://cloud.google.com/firestore/docs/resolve-latency); [Firebase: Best practices for Cloud Firestore (ramping up traffic)](https://firebase.google.com/docs/firestore/best-practices); [gRPC: Status codes](https://grpc.io/docs/guides/status-codes/).
## **Rather hand it over?**
Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.
- [from $450**App Fix Ticket**One reproducible bug in an existing mobile or web app, diagnosed and fixed.**See scope and start**](https://app369.com/fixed-price/flutter-firebase-bug-fix/)
- [from $450**AI-Built App Rescue**A Lovable, Bolt or Cursor app checked end to end in 3 days, then its worst problems fixed at a fixed price.****No issues worth fixing, no charge.**** If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.**See scope and start**](https://app369.com/fixed-price/ai-app-rescue/)
Related: [**Firestore quota exceeded**](https://app369.com/fix/firestore-quota-exceeded/) · [**Firestore “client is offline”**](https://app369.com/fix/firestore-client-is-offline/) · [**Cloud Functions memory limit exceeded**](https://app369.com/fix/firebase-functions-memory-limit-exceeded/) · [**Firestore query requires an index**](https://app369.com/fix/firestore-query-requires-an-index/)
Questions
## **More on this error**
**How long is the deadline? **+
Google’s Firestore error code page gives 60 seconds as the default deadline. A request that needs longer than that should be split into smaller reads or writes.
**Why does it happen inside a Cloud Function? **+
The same causes apply, plus the function’s own timeout. Await or return every Firestore call so the function doesn’t end before the write finishes, and page through large reads instead of loading a whole collection in one invocation. For thousands of writes, use the Admin SDK’s BulkWriter or batches of up to 500 instead of one huge Promise.all, and recursiveDelete for large deletes.
**Can you fix it for me? **+
If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.
A different error?
## **Describe it and get a written quote**
Send the error and what you were doing. You get a written scope, a fixed price and a timeline; Simon replies by email, usually within one business day.
[**Describe your problem **→](https://app369.com/contact/) [**All fixes**](https://app369.com/fix/)