429 / 503 · Retry-After · X-RateLimit
Got a 429? When can you retry?
Paste the response headers and get the exact answer: the absolute retry-at time in your local
zone, a live countdown, quota remaining, and what every header means. It untangles whether x-ratelimit-reset is
epoch seconds, milliseconds or a countdown, and whether Retry-After is seconds or a date — all in your browser.
One paste, three answers
Absolute time (local + UTC) and a live countdown — from Retry-After if present, else the reset header.
Auto-detects whether *-reset is epoch seconds, epoch ms, or seconds-until-reset, and shows which it used (with a manual override).
Reads limit / remaining / used and shows the remaining-percentage.
X-RateLimit-*, legacy RateLimit-*, the new IETF combined RateLimit + Policy, and GitHub / Twitter-X / Discord / GitLab.
Why it matters
Different APIs encode the reset time differently, so guessing wrong means retrying too early (and getting blocked again) or waiting far too long. ratelimitlens reads the headers with a disclosed, RFC-9110-based method — no black-box score — and converts them to one clear retry time. It’s a static page: nothing you paste is uploaded.
Frequently asked questions
What does ratelimitlens do?
Paste the raw response headers from a 429 / 503 (or any response) and it tells you the exact absolute time you are allowed to retry — in your local time and UTC — with a live countdown, how much quota is left, and a plain-English explanation of each rate-limit header. Everything runs in your browser; nothing is uploaded.
Is x-ratelimit-reset epoch seconds, milliseconds, or seconds-until-reset?
It depends on the vendor — which is exactly the confusion this tool resolves. GitHub, Twitter/X and GitLab use Unix epoch SECONDS; some APIs send epoch MILLISECONDS; the IETF RateLimit header and headers like x-ratelimit-reset-after use DELTA seconds (a countdown). ratelimitlens auto-detects by magnitude (≥1e12 → ms, ≥1e9 → epoch seconds, otherwise delta seconds) and shows which it used. If it guesses wrong, a one-click toggle lets you force the format.
How is Retry-After interpreted?
Per RFC 9110, Retry-After is either a number of seconds to wait (delta-seconds) or an absolute HTTP-date — never an epoch timestamp. ratelimitlens handles both and converts them to an absolute retry time and countdown.
Which header wins when several are present?
Retry-After is the server’s explicit “wait this long” instruction, so it headlines the retry time. If there is no Retry-After, the reset header (x-ratelimit-reset / RateLimit reset / reset-after / a reset HTTP-date) is used instead. Every header found is still shown in the breakdown.
Why might the countdown be slightly off?
Delta values (Retry-After: 60, x-ratelimit-reset-after: 60, and small reset numbers) are relative to when the server sent the response — not when you pasted. The tool assumes “now” is paste time, which is the best a header-only tool can do; absolute formats (epoch and HTTP-date) are exact. This is stated in the result.
Does it support the new IETF RateLimit header?
Yes — it reads the combined RateLimit header (limit / remaining / reset, including the r= and t= short forms) and RateLimit-Policy, as well as the legacy separate RateLimit-* and the X-RateLimit-* family used by GitHub, Twitter/X, Discord, GitLab and others.
Is my data safe?
Completely — this is a static page and all parsing happens in your browser with JavaScript. No headers are ever sent to a server, there is no backend, and nothing is logged.