# Firestore: ABORTED, too much contention on these documents

> Firestore returned ABORTED, too much contention: too many writes or transactions hit the same document. Use increment(), shard hot counters, retry with backoff.

Canonical: https://app369.com/fix/firestore-aborted-too-much-contention/
Last updated: 2026-11-09

ABORTED is the Firestore error for writes or transactions that collide on the same documents. Google lists three causes: too many updates per second to one document, overlapping transactions, and traffic spikes or hot spots. Counters are the usual example.

**Short answer**

Find the document everyone writes to, such as a likes counter or a stats doc. Replace read-then-write transactions with increment(), split hot counters into shards, and keep transactions short. Retry ABORTED writes with exponential backoff.

Rather not fix it yourself? [**App Fix Ticket**](https://app369.com/fixed-price/flutter-firebase-bug-fix/) starts with a fixed-price diagnosis, then a fixed price for the fix before any fix work.

## **Why Firestore aborts the write, and the fix**

1. 01 ### **One document gets too many updates**
  > “A document receiving too many updates per second.” [**Google Cloud, Error codes (ABORTED)**](https://cloud.google.com/firestore/docs/understand-error-codes) A counter, a leaderboard or a shared settings doc written by every user hits the per-document write rate. Split it into shards and add them up when you read.
2. 02 ### **A transaction reads before every write**
  > “A function calling a transaction (transaction function) might run more than once if a concurrent edit affects a document that the transaction reads.” [**Firebase, Transactions and batched writes**](https://firebase.google.com/docs/firestore/manage-data/transactions) A transaction that reads a counter and writes it back collides with every other user doing the same. increment() changes the number without a read.```
import { doc, updateDoc, increment } from 'firebase/firestore';

await updateDoc(doc(db, 'posts', postId), { likes: increment(1) });
```
3. 03 ### **Writes go to a narrow range of IDs**
  > “Avoid high read or write rates to lexicographically close documents, or your application will experience contention errors.” [**Firebase, Best practices**](https://firebase.google.com/docs/firestore/best-practices) IDs that always increase, like order1, order2 or timestamp-based IDs, put new writes next to each other. Let Firestore create IDs with add() or doc() with no ID.
4. 04 ### **Traffic jumped suddenly**
  > “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 (500/50/5 rule)**](https://firebase.google.com/docs/firestore/best-practices) A launch or import that goes from zero to thousands of writes a second can hit ABORTED while Firestore scales. Ramp up over minutes, and retry with backoff.

Checked against the vendor’s docs on November 9, 2026: [Google Cloud docs: Firestore error codes](https://cloud.google.com/firestore/docs/understand-error-codes); [Firebase docs: Transactions and batched writes](https://firebase.google.com/docs/firestore/manage-data/transactions); [Firebase docs: Best practices](https://firebase.google.com/docs/firestore/best-practices); [Firebase docs: Distributed counters](https://firebase.google.com/docs/firestore/solutions/counters).

## **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/)

[**All 127 Fiverr reviews**](https://app369.com/reviews/)

Related: [**Firestore DEADLINE_EXCEEDED**](https://app369.com/fix/firestore-deadline-exceeded/) · [**Firestore transaction too big**](https://app369.com/fix/firestore-transaction-too-big/) · [**Firestore quota exceeded**](https://app369.com/fix/firestore-quota-exceeded/) · [**Firestore document too large**](https://app369.com/fix/firestore-document-too-large/)

Questions

## **More on this error**

<details>

<summary>**Is it safe to retry an ABORTED write? **+</summary>

SDKs retry transactions a few times. If it still fails, retry with backoff, and make other writes safe to repeat so a retry can’t double count.

</details>

<details>

<summary>**Does increment() remove the limit? **+</summary>

No. It removes the read, so transactions stop colliding, but one document still has a write rate limit. Use shards for very busy counters.

</details>

<details>

<summary>**Can you fix it for me? **+</summary>

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.

</details>

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/)