Magento 2 : Fixing Elasticsearch's "TOO_MANY_REQUESTS/12" Error: Flood-Stage Disk Usage

I wrote these tutorials for myself in future when I forget for the next steps.
Search for a command to run...

I wrote these tutorials for myself in future when I forget for the next steps.
No comments yet. Be the first to comment.
When you provision an Ubuntu instance on Oracle Cloud, you'll notice something different from standard Ubuntu installations: the system uses iptables instead of ufw for firewall management. This disti

When developing web applications locally, HTTPS is often overlooked. Yet, modern browsers and APIs increasingly require secure connections—even in development. That’s where mkcert comes in: a simple t

Testing the checkout success page in Magento 2 can be frustrating. By default, once an order is placed, Magento clears the quote session, meaning you can’t simply refresh or revisit the success page without going through the entire checkout process a...

Magento Commerce (EE) offers powerful features, but for many teams, Open Source (CE) is leaner, lighter, and more sustainable. If you're migrating from EE to CE, the Opengento downgrade tool provides a clean, scriptable way to remove proprietary modu...

If you’ve ever checked your Apache error logs and seen something like this: Code [core:error] (13)Permission denied: access to /robots.txt denied (filesystem path '/home/username/sites') because search permissions are missing on a component of the pa...

During a recent Magento 2.4.4 development sprint, I ran into a puzzling indexing error that might look familiar to fellow devs working with Elasticsearch:
Catalog Search index process error during indexation process:
index [magento244p13_product_1_v1] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block]
In plain terms: Elasticsearch panicked because disk usage passed the flood-stage watermark (typically 95%), so it slammed the brakes and marked the index as read-only. Magento couldn’t update the index because of it.
Here’s how I solved it, step-by-step.
First, I ran:
bash
df -h
Sure enough, my disk space was on the brink. A quick cleanup of old logs and unused packages brought it under control.
After freeing space, I lifted the restriction on all indexes with:
bash
curl -XPUT -H "Content-Type: application/json" \
http://localhost:9200/_all/_settings \
-d '{"index.blocks.read_only_allow_delete": null}'
In stubborn cases, this broader setting can help:
bash
curl -XPUT -H "Content-Type: application/json" \
http://localhost:9200/_cluster/settings \
-d '{
"transient": {
"cluster.routing.allocation.disk.threshold_enabled": false
}
}'
With the block removed, I ran:
bash
bin/magento indexer:reindex
And this time—no errors. Clean as a whistle.
Takeaway: Keep a close eye on your Elasticsearch node’s disk usage—especially in local or staging environments with limited storage. Flood-stage blocks are protective but disruptive. This simple reset can save hours of head-scratching.