Design Rate Limit and Quota Messaging

Feedback & States · errors, microcopy, enterprise

Updated 2026-07-28

Never make a limit a surprise. If an action can be refused because of a cap, the cap should be visible before the user starts, not after they finish.
Say which limit was hit and what it applies to. Per minute, per day, per account, and per plan all lead the user to different conclusions.
Say when it resets, as a time rather than a duration. "Available again at 14:20" is checkable, and "try again later" is not.
Never lose the work. A refused submit must keep the content so the user can retry when the window opens rather than writing it again.
Separate a temporary limit from a permanent one. Slowing down is a wait, and running out of plan allowance is a decision, so the wording and the actions differ.
Warn on approach, not only on arrival. A quiet note at eighty percent lets people plan, and a hard stop at one hundred does not.
Offer the honest next step, which might be waiting, reducing the batch size, or upgrading. If upgrading is the answer, say what the new limit would be.
Keep the tone neutral. A limit is a system constraint, and phrasing it as if the user did something wrong is both inaccurate and irritating.
Show usage where the user can find it without hitting the wall, such as in settings or on the account page.

Limits are a normal part of a product, and users only resent them when they arrive without warning or explanation.