diff --git a/TOOLING.md b/TOOLING.md
index b83cd9b..79909a6 100644
--- a/TOOLING.md
+++ b/TOOLING.md
@@ -247,6 +247,61 @@ A stories-only run adds few files and often **none** — profiles frequently hav
 no active story. "0 new" is a normal result, not a failure. `fileCount` in
 `/api/archives` is stale by design; use the per-profile `/files` listing.
 
+## 2026-08-21 — scraping warning, automation stopped
+
+**Instagram flagged the account.** Not suspended: an interstitial at
+`/accounts/scraping_warning/` reading *"We suspect automated behaviour on your
+account"*. It was dismissed in the browser and the account is healthy — feed
+loads, still signed in. **All three timers are disabled.** Do not re-enable
+them without deciding the cadence question below.
+
+How it unfolded, because each step misled in a different way:
+
+1. **09:13** the daily timer fired, exited 0 in one second, logged
+   `done; 0 step(s) failed` — and fetched nothing. Yesterday's manual run was
+   18.9–19.2h earlier, just under the `--min-interval 20` floor, so all six
+   sources were skipped. **A silent no-op on the one surface that cannot be
+   backfilled, reported as success.**
+2. **20:28** `chrome-devtools.service` was OOM-killed (5.1 GB peak, ~1w3d CPU).
+   Unrelated to the above, and it does not break fetching — gallery-dl reads
+   the cookie *file*, not a live browser — but it meant no browser was running
+   to notice anything was wrong.
+3. **23:19** a manual recovery run passed the floor (33h) and every source
+   failed with `400 Bad Request` on
+   `/api/v1/feed/reels_media/?reel_ids=…`. Six identical failures across six
+   profiles is not a per-profile fault.
+4. Cookies were **exported and checked before assuming a block**:
+   `sessionid` 77 chars, printable, colon-delimited, 360 days to expiry;
+   `ds_user_id` present. Decryption was fine, so the fault was server-side.
+   This check costs no Instagram requests and should always come first.
+5. The browser then showed the interstitial. The 400s were the challenge
+   state, not a ban.
+
+### What has to change before automation is re-enabled
+
+- **The `--min-interval` floor silently defeats the daily job.** Any manual run
+  in the preceding 20h makes the scheduled one a no-op. The floor exists to
+  stop an *aborted restart* re-enumerating profiles — a minutes-to-hours
+  concern — and a stories fetch is one request per profile. `stories` should
+  use something like `--min-interval 8`, not 20.
+- **A skipped stories run must be loud.** `0 to sync, 6 skipped` currently
+  exits 0 and looks identical to success. On this surface a skip is a real
+  loss, and it should be visible in the journal without reading the log.
+- **Reconsider the daily cadence itself.** A job hitting story endpoints for
+  six profiles every morning is the most machine-like thing here, randomised
+  delay or not, and it is what was flagged. Every-few-days, or on-demand, may
+  be the honest answer even though stories will be missed.
+- **`chrome-devtools.service` has `Restart=no`** and died silently for three
+  hours. It needs `Restart=on-failure` and probably a `MemoryMax=`, or it will
+  be dead the next time the cookie needs refreshing.
+
+### Cost of the pause
+
+`official_artms` and `0ct0ber19` both had active stories on the evening of
+2026-08-21 that will expire uncollected. That is the price of stopping, and it
+is the right trade: spending requests on story endpoints minutes after
+clearing a scraping warning is exactly the behaviour that was flagged.
+
 ## What changed on 2026-08-20
 
 One session, three separate pieces of work. Recorded because the reasons are