A matching-engine restart changes the execution checklist

A restart is not just a slower API response. It is a temporary change in what the trading system will accept.

Polymarket's matching-engine guidance describes a simple operating rule: pause new work during the restart, then resume under post-only restrictions for the documented window.

Detect the specific condition

Order-related actions can reject while the engine is restarting. Treat that signal as temporary, but do not apply restart retries to unrelated failures such as an unclassified service error.

Keep the rejection type, any server-provided delay, and the request identifier together in the log. That record tells you whether the process waited for the right reason.

Let the server set the delay

When a retry delay is supplied, honor it. When it is absent, use bounded exponential backoff rather than sending the same signed request in a tight loop.

The aim is not to win a race against the restart. It is to avoid turning a maintenance window into a burst of duplicate or stale submissions.

Resume with the right order mode

After restart rejections stop, the engine enters post-only mode for two minutes. Cancels remain available, while new orders must be eligible maker orders submitted as post-only.

A normal limit order is not made safe by retrying it unchanged. Re-check the order's intent, confirm it is eligible to add liquidity, and only then submit under the temporary mode.

Check every item in a batch

A batch request can be accepted at the request level while individual orders are rejected. Inspect each result before marking the batch successful and before assuming any exposure was created.

The practical checklist is short: classify the restriction, wait the indicated time, adapt the order mode, inspect per-order results, and fetch current state before declaring the workflow recovered.

Further reading: Matching engine restarts · Manage orders · Order lifecycle.

Explore the markets: Open Polymarket (referral link).