A 429 response may include Retry-After; the header is optional. Its value can express seconds counted from response receipt or an HTTP date. Neither form promises that another request will succeed. See RFC 6585, section 4, and MDN Retry-After definitions.
Two time references
Both examples below are hypothetical. Assume receipt at 12:00:00 GMT on 26 October 2026. No response was captured and no retry was performed.
Delay-seconds example: Retry-After: 120 gives an interval ending at 12:02:00 GMT. The calculation is receipt time plus 120 seconds, not request-start time plus 120 seconds. This form uses a whole-number value of zero or greater.
HTTP-date example: Retry-After: Mon, 26 Oct 2026 12:03:00 GMT names 12:03:00 GMT. With the assumed receipt time, that is 180 seconds later. Unlike the first form, the value names a time rather than a duration. The two forms follow MDN syntax and directives; the arithmetic is illustrative.
Timing and retry behavior
RFC 6585 does not prescribe one universal request-counting scope or user-identification method. Do not turn a waiting value into an assumed quota. See RFC 6585, section 4.
For practical review, keep three questions separate: what time the header indicates, whether the client will retry, and what happened after an actual attempt. Confirm client behavior and service limits in their applicable documentation rather than treating the diagram as an implementation specification.
The next response to inspect
Use one response you control. Record its header value and receipt time, then identify the form before calculating. If the value is missing or unclear, record that uncertainty instead of inventing a delay. Leave the outcome as not observed until an actual attempt supplies evidence.
Source basis: supplied documentation captures dated 25 October 2026; no new source check or live availability check was performed. Refresh this explanation if the documented semantics or applicable client/service instructions change.
