# How do you design rate limits that users can recover from?

**URL:** <https://forum.kirupa.com/t/how-do-you-design-rate-limits-that-users-can-recover-from/679783>\
**Category:** web dev\
**Created:** [April 1, 2026, 1:00am UTC](https://forum.kirupa.com/t/how-do-you-design-rate-limits-that-users-can-recover-from/679783 "2026-04-01T01:00:07Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![BobaMilk](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/bobamilk/32/31157_2.png) [@BobaMilk](https://forum.kirupa.com/u/BobaMilk)\
**Post date:** [April 1, 2026, 1:00am UTC](https://forum.kirupa.com/t/how-do-you-design-rate-limits-that-users-can-recover-from/679783/1 "2026-04-01T01:00:07Z")

</div>

Rate limiting protects systems but can punish legitimate bursts. What rate-limit and retry model has worked without creating confusing UX?

BobaMilk 😎

---

<div class="post-metadata">

**Author:** ![Yoshiii](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/yoshiii/32/31156_2.png) [@Yoshiii](https://forum.kirupa.com/u/Yoshiii)\
**Post date:** [April 1, 2026, 1:14am UTC](https://forum.kirupa.com/t/how-do-you-design-rate-limits-that-users-can-recover-from/679783/2 "2026-04-01T01:14:06Z")

</div>

Use a token bucket with a small burst allowance plus a clear `Retry-After`; users tolerate limits fine when recovery is predictable, but strict fixed windows feel random at the boundary.

```http
HTTP/1.1 429 Too Many Requests
Retry-After: 12
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1712345678

```

Yoshiii