Most accounts are not lost to a single policy — they are pushed deeper by their own retry logic while already unhealthy.
When an interface errors or rate limits, retrying feels natural. But if the trigger is account-level throttling rather than a transient blip, every retry is recorded as another write request: failure rates climb, the account profile looks worse, and the spiral reinforces itself.
Worse, retries cluster in the same time window — a burst of write attempts is itself a conspicuous pattern.
At least three: repeated rate-limit or permission errors, a visible drop in write success rate (three consecutive failures, say), and any explicit platform warning or feature restriction.
Thresholds need numbers and a window. 'Three write failures within ten minutes for the same account' is actionable; waiting for dozens of failures is not. Tier the thresholds by account age if you like, but make them explicit.
Stop, record, alert, get a human decision, then recover in stages. Capture the evidence — error code, time, account, egress — and hand control to someone who knows the business context. Recover from the smallest actions: reads before writes, single items before batches.
We ship this as platform behaviour: rate control on writes, automatic back-off on anomalies, Telegram alerts, and per-account recovery rather than one global retry storm.
A breaker is valuable precisely because nobody has to watch it. With a fleet, nobody can. Encoding 'slow down on failure' as a default beats writing an emergency runbook that nobody reads.
One counter-intuitive conclusion: lowering daily caps and widening spacing costs throughput in the short run, but extends the life of the accounts — and accounts are the expensive asset, not the quota.
Say an account starts returning limit errors on the third DM of a batch. Stop the batch, record the error code with the timestamp and the egress in use, and alert the owner. Do not enqueue the remaining messages.
Wait for the window to pass, then resume with a single item and observe the result. If it succeeds, continue at half the original pace for the rest of the day; if it fails again, the breaker stays closed and the account goes back to a human. Record the outcome either way, because the next incident is easier to judge when you have the previous one written down.
The pattern to avoid is the one that feels productive: retrying immediately, raising the cap to catch up, and letting several accounts run the recovery at once. Each of those turns a single throttled write into a fleet-wide signal.
It delays rather than drops: tasks stay queued and resume at a controlled pace once the breaker clears.
No. Limits are interface-level and usually recover with slower pacing; bans act on the account and are far harder to reverse. That is why you stop at the limit stage.
Look at scope: several accounts behind the same egress failing together points at the egress or the platform; one account failing alone points at that account.
Most accounts are not lost to a single policy — they are pushed deeper by their own retry logic while already unhealthy.