Jun 08, 2026·6 min read

Share|

Category:Automation›Crypto

Bybit error 10006: params timestamp illegal — why it happens and how to fix it

When Bybit returns error 10006 "params timestamp illegal": why your trading bot's requests are rejected, the difference from Binance -1021, and the clock sync that prevents it.

Free download: Exchange API ban prevention runbook. Jump to the download section.

Bybit error 10006 with message "params timestamp illegal" means your request timestamp is outside Bybit's allowed time window.

It is functionally similar to Binance -1021 but with important differences in error handling, recvWindow defaults, and recovery behavior. If you handle both exchanges in the same bot, you need exchange-specific timestamp validation.

Fast triage table (what to check first)

What Bybit error 10006 actually means

Bybit's error 10006 is documented as "params timestamp illegal."

{
  "retCode": 10006,
  "retMsg": "params timestamp illegal",
  "result": {},
  "retExtInfo": {},
  "time": 1717000000000
}

It means the timestamp field in your signed request differs from Bybit's server time by more than the allowed window (default 5000ms). Bybit compares your timestamp parameter with its own server clock and rejects requests outside the tolerance.

Bybit vs Binance: key differences

The practical difference is error messaging. Binance tells you directly that the timestamp is outside recvWindow. Bybit says "params timestamp illegal" which is less specific. Your bot should log the actual clock offset regardless.

Common causes

1) Clock drift (most common)

Same as Binance -1021: your system clock drifted past the tolerance window. See Binance -1021: timestamp outside recvWindow for the detailed drift mechanics.

2) Wrong timestamp unit

Bybit expects Unix time in milliseconds. If your code sends seconds (or nanoseconds), the timestamp will be far outside the window.

// Correct (milliseconds)
const timestamp = Date.now(); // -> 1717000000000
 
// Wrong (seconds) — far outside window
const timestamp = Math.floor(Date.now() / 1000); // -> 1717000000 -- ~50 years off

3) Fresh timestamp per request not being used

If your code reuses a cached timestamp or generates it before an async delay, the timestamp can be stale by the time the request reaches Bybit.

4) recvWindow set too low

Bybit supports recvWindow in the request body. If you set it to 1000 or lower, even small clock jitter triggers 10006.

How to fix 10006

1) Check clock offset against Bybit

# Get your current Unix timestamp (milliseconds)
python -c "import time; print(int(time.time() * 1000))"
 
# Get Bybit server time
curl -s https://api.bybit.com/v5/market/time | python -c "import sys,json; print(json.load(sys.stdin)['time'])"

Compare the two values. If the difference exceeds your recvWindow (default 5000ms), your clock is the cause.

2) Sync NTP

# Linux
sudo ntpdate -u pool.ntp.org
sudo systemctl restart systemd-timesyncd

3) Verify timestamp unit is milliseconds

// Bybit signed request — correct timestamp format
const timestamp = Date.now(); // milliseconds
const recvWindow = 5000;
 
const params = {
  category: 'spot',
  symbol: 'BTCUSDT',
  side: 'Buy',
  orderType: 'Limit',
  qty: '0.001',
  price: '50000',
  timeInForce: 'GTC',
  timestamp: timestamp,
  recvWindow: recvWindow,
  sign: signature
};

4) Add recvWindow as a safety buffer

Always include recvWindow in your signed requests. Bybit's default is 5000ms. Keep it at 5000 unless you have a specific reason to change it.

What NOT to do on 10006

Do not retry blindly

Error 10006 will persist until the clock is fixed. Retrying with drift is wasted work that can trigger rate limiting.

Do not confuse 10006 with other Bybit errors

If you treat 10006 like 10028 (rate limit) and just backoff, your requests will keep failing until the clock is fixed.

What to log

If you cannot answer these questions after a 10006 event, you are guessing:

• What was the clock offset (local time vs Bybit server time)?
• Was the timestamp in seconds or milliseconds?
• Was the offset consistent across all instances?
• Was the error intermittent or persistent?

Log per signed request:

• ts
• bot_instance_id
• exchange (bybit)
• endpoint
• method
• ret_code (10006)
• ret_msg (params timestamp illegal)
• local_timestamp_ms
• server_timestamp_ms (from Bybit time endpoint)
• offset_ms
• recvWindow_configured
• timestamp_unit (ms | s)

Shipped asset

Related tools

• Timestamp Drift Checker — Check your clock drift against Bybit, Binance, Kraken, Coinbase and other exchange server times.
• Exchange Error Lookup — Look up Bybit error 10006, Binance -1021, and 25+ exchange error codes with recovery actions.

Resources

• Exchange API ban prevention runbook
• Timestamp drift prevention package
• Signature invalid but bot was working: why clock drift breaks auth suddenly
• Binance error -1021: timestamp outside recvWindow
• Crypto Automation hub
• Bybit API error codes documentation

Checklist (copy/paste)

• NTP sync is configured and running on all instances.
• Timestamps are in milliseconds (Date.now(), not seconds).
• Each signed request uses a fresh timestamp (no caching or reuse).
• recvWindow is set to 5000 (default) on all signed requests.
• Clock offset (local vs Bybit server) is logged per signed request.
• 10006 is treated as a STOP rule: fix clock first, then resume.
• Error 10006 is handled separately from 10001, 10003, 10004, and 10028.
• Post-deploy health check verifies clock sync.

Key takeaways

• Bybit error 10006 "params timestamp illegal" means your request timestamp is outside the allowed window (default 5000ms).
• Same root cause as Binance -1021: clock drift. Less descriptive error message, same fix: sync NTP.
• Verify your timestamp is in milliseconds, not seconds. Seconds sends a value ~50 years off.
• Treat 10006 as a stop rule: fix the clock first, then resume signed requests.
• Log clock offset per request and distinguish 10006 from other Bybit auth errors (10001, 10003, 10004).
• Use the Timestamp Drift Checker and Exchange Error Lookup to diagnose cross-exchange timestamp issues.

Related posts

Automation > CryptoJun 07, 2026

Binance error -1021: timestamp for this request is outside the recvWindow

When your trading bot flips from working to "timestamp for this request is outside the recvWindow": why Binance rejects valid signatures after clock drift, and the time calibration that prevents -1021.

Automation > CryptoJan 09, 2026

Signature invalid but bot was working: why clock drift breaks auth suddenly

When bot gets signature invalid or 401 after working fine for hours: why clock drift breaks exchange auth suddenly, and the time calibration that prevents it.

Automation > CryptoJun 06, 2026

WebSocket closed with 1006: why trading bots lose connection without an error code

When WebSocket drops with 1006 abnormal closure and no close frame: why trading bots see 1006 instead of a clean close, and the reconnect strategy that handles it without guessing.