What is recvWindow? Binance's request time window explained

CoTrading editorial team 2026-09-23

Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs.

recvWindow is an optional parameter on Binance’s signed requests that sets how many milliseconds may pass between the request’s timestamp and the moment Binance’s server evaluates it; it limits how late a request may be, and has no effect on how early.

That last clause is the whole reason this page exists. recvWindow is the knob people reach for when they see -1021, and in one of the two situations that produce -1021 it does nothing at all. This page covers the rule Binance actually applies, what the parameter can and cannot fix, how Bybit’s equivalent works, and where the value should sit in your client.

Why this matters now

Binance attaches two different messages to one error code, -1021 INVALID_TIMESTAMP:

“Timestamp for this request is outside of the recvWindow.”
“Timestamp for this request was 1000ms ahead of the server’s time.”

Most troubleshooting advice treats them as one problem with one fix: raise recvWindow. That advice is sometimes harmless, sometimes useless, and occasionally hides a fault that keeps getting worse. Telling the two messages apart takes seconds and decides what you should do next.

How it actually works

You send a timestamp with every signed request, in milliseconds or microseconds.
You may send recvWindow. On Binance spot it defaults to 5000 ms, has a maximum of 60000 ms, and accepts up to three decimal places for microsecond precision. Binance recommends 5000 or less.
It is an ordinary request parameter, so it sits inside the signed payload with everything else. Changing it after signing breaks the signature — see HMAC request signing.

Binance applies one check, published as pseudocode:

if (timestamp < (serverTime + 1 second) && (serverTime - timestamp) <= recvWindow)

Each half of that condition has its own failure message. A request older than recvWindow fails the second half (“outside of the recvWindow”). A request stamped more than a second in the future fails the first half (“1000ms ahead of the server’s time”).

Drawn on a timeline, the accepted zone looks like this:

  too old            accepted                   too far ahead
 ─────────|──────────────────────────|────────|───────────────▶ timestamp
   serverTime − recvWindow       serverTime   serverTime + 1000 ms

Only the left edge moves when you change recvWindow. The right edge is a fixed one second.

USDⓈ-M futures uses the same check and the same default of 5000 ms. We did not find a stated maximum on the futures General Info page, so do not assume the spot ceiling carries over.

What recvWindow can and cannot fix

What happened	Message you see	Does a larger `recvWindow` help?
Request spent a long time in transit	“outside of the recvWindow”	Yes, within the maximum — at a cost described below
Your client stamped the request, then held it in a local queue or rate limiter	“outside of the recvWindow”	Superficially; the real fix is stamping at send time
Your clock runs slow and keeps drifting	“outside of the recvWindow”	Temporarily, until the drift outgrows the new window
Your clock runs fast by more than a second	“1000ms ahead of the server’s time”	No. The one-second limit does not depend on `recvWindow`
Timestamp sent in seconds instead of milliseconds	“outside of the recvWindow”	No. The value is decades in the past
A retry reused the original timestamp and signature after the window passed	“outside of the recvWindow”	No. Build and sign a fresh request

Two rows deserve emphasis.

The local-queue case is common and easy to miss. If your code generates the timestamp, then waits for a rate limiter, a lock or a connection slot, that wait is spent from the window before the request leaves the machine. The server sees a request that looks slow on the network when it was slow in your own process. A weight-based limiter like Binance’s makes this more likely — see what is request weight.

The fast-clock case is the one no parameter can reach. If the “ahead of the server’s time” message appears, the only fix is the clock. The diagnosis and the NTP checklist are in clock sync and timestamp errors.

Why widening it is not a clock fix

It only moves one edge. A slow clock is hidden; a fast clock is not.
Drift does not stay still. A clock that is two seconds behind today can be ten seconds behind next week. A wider window postpones the error and removes the early warning.
The window has a ceiling. On spot you cannot go past 60000 ms, so a drifting clock eventually breaks through anyway.
It weakens a protection. The window bounds how long a captured signed request remains usable. Bybit states the same idea directly: a smaller window “is more secure”.
Late orders are a trading problem, not just an auth one. An order that arrives many seconds after you priced it was priced for a market that has since moved. A short window turns a badly delayed order into a rejection, which is usually the outcome you would have chosen.

recvWindow vs Bybit’s recv_window

Bybit uses the same idea with a different transport.

	Binance	Bybit V5
Where it goes	`recvWindow` request parameter	`X-BAPI-RECV-WINDOW` header
Default	5000 ms	5000 ms
Published maximum	60000 ms (spot); none found for USDⓈ-M	Not captured in our fact card
Rule	`timestamp < serverTime + 1000` and `serverTime − timestamp <= recvWindow`	`server_time − recv_window <= timestamp < server_time + 1000`
Signed?	Yes, as part of the query string or body	Yes, explicitly: `timestamp + api_key + recv_window + queryString` or body
Error when outside	`-1021`	`10002`, “The request time exceeds the time window range.”

The inequality is the same shape on both: a configurable tolerance for being late, a fixed tolerance of under a second for being early. Bybit’s guide recommends keeping local time NTP-synchronised and serves its clock at GET /v5/market/time. See Bybit API error 10002.

Not every venue has the parameter. OKX applies a fixed tolerance — requests more than 30 seconds from server time are rejected with 50102 — and there is nothing to tune. Hyperliquid replaces the timestamp window with a nonce that must fall within a wide validity range, and puts freshness in an optional expiresAfter field instead. Timestamp tolerance compared sets the models side by side.

Where the boundary should sit

Stamp at the last moment. Generate timestamp immediately before signing and sending, after any queue, limiter or lock — never when the request is first constructed.
Leave the default unless you have measured a reason. If you do raise it, raise it for a specific route you have measured, not globally.
Log the server-time delta at startup. One call to the venue’s time endpoint turns a mystery into a number.
Fail fast on the “ahead” message. It cannot be retried away, so route it to an alert rather than a retry loop — a model calling tools will otherwise keep trying. See retrying a failed order is not safe.
Re-sign every retry. A retry is a new request with a new timestamp and a new signature.

FAQ

What is recvWindow in the Binance API?

It is an optional parameter on signed requests that sets how many milliseconds after its timestamp a request may be evaluated and still accepted. On Binance spot it defaults to 5000 ms and cannot exceed 60000 ms. It only limits how late a request may be; a request stamped more than one second ahead of server time is rejected regardless of its value.

Does increasing recvWindow fix error -1021?

Only for the “outside of the recvWindow” message, and only when the cause is transit or queueing delay. For the “1000ms ahead of the server’s time” message it has no effect, because that limit is fixed. In both cases a drifting clock should be fixed with time synchronisation rather than hidden with a larger window.

What is the maximum recvWindow on Binance?

On spot, Binance documents a maximum of 60000 ms and a default of 5000 ms, and recommends using 5000 or less. For USDⓈ-M futures the documented default is also 5000 ms, but we did not find a stated maximum on the futures General Info page, so check the current documentation before relying on a larger value.

Is Bybit’s recv_window the same as Binance’s recvWindow?

The rule is the same shape: a configurable tolerance for late requests and a fixed tolerance of under one second for early ones, with a 5000 ms default on both. Bybit sends it as the X-BAPI-RECV-WINDOW header and includes it in the signed string; failures return 10002 rather than Binance’s -1021.