Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
When a server returns HTTP 429, check for a Retry-After header and wait as instructed before sending another request. Ignoring that signal can keep requests arriving during the server’s stated cooldown and prolong failures. The headline’s “2-second blip” and “4-minute lockout” describe a particular incident only if its logs or a first-party account verify those timings; HTTP standards do not guarantee that outcome.
What does HTTP 429 mean?
HTTP 429, “Too Many Requests,” means the user has sent too many requests in a given amount of time. The status code identifies rate limiting, but it does not define one universal limit or reset interval. RFC 6585 leaves the counting method and requester identification to each server’s implementation.
A service might count requests for one resource, across a server, or across multiple servers. It may identify a requester using credentials or cookies. Consequently, a 429 alone does not reveal whether the limit applies to an account, an IP address, a particular endpoint, or another scope. RFC 6585, section 4 describes both the status and this implementation flexibility; MDN’s 429 reference also notes that rate-limit behavior varies.
Free tools Windows power users keep installed
One-click scans. No signup required.
What does Retry-After tell you?
A 429 response may include Retry-After to indicate how long to wait before making a new request. It is optional: not every 429 response contains the header. When present, its value can be either a delay in seconds or an HTTP-date, so a client must handle both forms rather than assuming the value is always a number.
#1 Best Overall
RFC 9110 says the field indicates how long a user agent ought to wait before a follow-up request. In other words, it is the server’s timing guidance for that response—not a guarantee that the next request will succeed. See RFC 9110, section 10.2.3 and RFC 6585, section 4.
How should a client handle Retry-After?
- Inspect the 429 response. Read the status and check whether a
Retry-Afterheader is present. - Parse its format. Treat a valid value as either a delay in seconds or an HTTP-date, as defined by RFC 9110.
- Wait before following up. Do not send another request before the supplied time has elapsed. If the header is absent, the service has not supplied this timing instruction; any fallback policy is a client implementation choice, not a schedule prescribed by these RFCs.
- Bound retries and coordinate workers. Avoid an unbounded stream of repeated attempts, including attempts from concurrent workers. The standards establish the meaning of the response and header, but do not prescribe one universal retry algorithm or fallback schedule.
- Check whether the operation is safe to repeat. Apply the method-specific safeguards described below before retrying a request that might have changed server state.
Sending requests before the indicated wait ends means continuing to contact a server that has asked the client to delay. That can prolong failed attempts, but the eventual duration depends on the service’s rate-limit policy; HTTP does not mandate a four-minute wait or lockout.
Can you retry a POST after a 429?
Not automatically in every case. A client must consider whether repeating the request could apply an operation twice. RFC 9110 says clients should not automatically retry a non-idempotent method unless they know the operation is idempotent or can determine that the original request was not applied.
For a POST, use the API’s documented safeguards—such as an idempotency mechanism, if the service provides one—or otherwise establish that the first operation did not take effect before retrying. A 429 response alone is not a blanket assurance that repeating a state-changing request is safe. The relevant guidance is in RFC 9110, section 9.2.2.
What the “2-second” and “4-minute” timings establish
Those figures are not universal HTTP behavior. The standards establish that 429 signals rate limiting and that a response may tell the client how long to wait. They do not establish that a two-second event will cause a four-minute lockout. To attribute those exact timings to an incident, the evidence would need to include its response headers and request timestamps, or a reliable first-party account. Without that, treat the numbers as case-specific framing, not a general rule.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why rate limits differ between services
There is no single HTTP-wide rate-limit window, identity key, or reset behavior. A service chooses what it counts and how it identifies the requester. For a concrete but narrowly scoped example, Cloudflare’s support documentation, last updated August 14, 2026, lists a limit of 1,200 requests per five-minute period per user and a Client API limit of 200 requests per second per IP. Those are Cloudflare-documented limits, not general HTTP limits or defaults for other APIs. See Cloudflare’s 429 documentation.
Quick Recap
Best Value
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
