Running a Polymarket bot 24/7: hosting, reconnects, rate limits, kill switches and the boring things that decide everything

The operations layer most bot tutorials skip: where to host, how to survive restarts without orphaned orders, WebSocket reconnects and stale-data guards, the two-layer rate limits and how to budget them, monitoring and alerts, kill switches that ship on, secrets, and how to not get broken by the next API change.

By the POLBOTS editorPublished Aug 21, 20265 min read
On this page9 sections

Where it runs

A bot that holds positions needs to be on a machine that does not sleep. A small VPS — a few dollars a month, one vCPU, a gigabyte of memory — is enough for almost every strategy in the catalog; the exceptions are the latency games (sniping, spot-lead on the minute markets) where proximity to Polymarket's infrastructure starts to matter and people pay for it. Put the bot in a container or a virtual environment, pin its dependencies, and never run it as the machine's root user.

Surviving restarts

Processes die: the host reboots, the bot hits an unhandled exception, you deploy. A process supervisor — systemd, pm2, a container restart policy — brings it back; what happens next is on you.

  • Persist state — open orders, positions, the strategy's own variables — to disk or a small database, continuously. A bot that keeps state only in memory forgets its positions every restart.
  • Start deliberately. On boot, either cancel every resting order and begin clean, or reload them on purpose from the exchange and reconcile. Never assume the world paused while you were down.
  • Make start-up idempotent. Starting twice by accident should not place orders twice.
  • Log what you did, with timestamps, to a file that survives the process.

Staying connected

The bot lives on WebSockets — the market channel for the books it trades, the user channel for its own fills. Both require a client heartbeat and both drop. Reconnect with exponential back-off; resubscribe; take a fresh REST snapshot of every book before trusting it again, because a book rebuilt across a gap is wrong in ways that look right. And define "stale": if no update has arrived on a book for longer than your strategy tolerates, stop quoting it and, for makers, pull your orders. A maker with stale quotes in a moving market is paying everyone.

Rate limits, budgeted

Two layers, and a bot in production meets both. Per IP, in ten-second windows at the edge: at the time of writing 9,000 CLOB requests in general, 1,500 each for the book, price and midpoint endpoints, 300 for Gamma's market list, 5,000 burst for single-order placement, 250 for cancel-all. And since July 2026, per signing key: token buckets for placing and for cancelling that refill at a rate set by your 30-day maker volume; run one dry and you get 429 with Retry-After and remaining-budget headers. The warning phase is over — these are enforced.

So: subscribe rather than poll; batch orders (up to fifteen) and cancels; keep a local budget per endpoint so the bot slows itself before the edge does; and on 429, wait exactly as long as the header says. The API guide has the shape of the limits; the docs' two rate-limit pages have the current numbers.

Monitoring and alerts

You cannot watch it, so it must tell you. The minimum set, pushed to Telegram, Discord or wherever you will actually see it:

  • A heartbeat every few minutes, and an alert when it stops.
  • PnL and exposure — realised, unrealised, per market and total — on a schedule.
  • Reconciliation diffs: whenever the exchange's view of your positions or open orders disagrees with the bot's.
  • Error rates: rejections, 429s, reconnects.
  • Balance changes that the bot did not cause.
  • A "last fill" timestamp — a taker bot that has not filled in an hour is either out of edge or out of order.

Kill switches that ship on

The difference between a bot that loses a bad day and a bot that loses an account is whether it stops itself. The best minute-market bots ship these enabled by default, and that is the standard: a daily loss cap (cancel everything and halt), a losing-streak breaker, an unfilled-ratio breaker for taker strategies (if your orders stop filling, the market has moved past you), a volatility guard that skips violent stretches, position and open-order caps, and a manual cancel-all-and-halt you can trigger from your phone. Build them before the strategy is finished; you will not want to afterwards.

Secrets and keys

Signer key and L2 credentials in environment variables or a secrets manager on the server; never in the repository, never in logs, never in the chat where you paste stack traces. One account per bot, funded only with working capital, profits swept out on a schedule — the wallets guide covers the rest. And watch the bot's wallet independently: its positions and fills are public, and a tracker on your own address is the cheapest audit there is.

Not getting broken by the next change

The CLOB cutover to V2 on 28 April 2026 stopped every V1 bot the same morning: bots built on the archived py-clob-client, on USDC.e, on a signed fee rate. The unified SDKs replaced even the interim -v2 packages soon after; the per-signer rate limits went from warning to enforced in July. Changes like these are announced — subscribe to Polymarket's changelog and status page, pin your SDK version and read release notes before you bump it, and keep a dry-run mode you can run against production data after any upgrade. A bot nobody maintains is a bot that stops, usually at a time of the exchange's choosing.

The checklist

  1. VPS, container or venv, pinned dependencies, non-root.
  2. Supervisor with restart; persisted state; deliberate, idempotent start-up.
  3. WebSocket reconnect with back-off, resubscribe, fresh snapshots, a stale-data rule.
  4. Per-endpoint request budget; batching; Retry-After honoured.
  5. Heartbeat, PnL, reconciliation, errors and balance pushed to you.
  6. Kill switches on by default; a manual halt in your pocket.
  7. Secrets on the server only; one small account per bot; profits swept.
  8. Changelog and status subscribed; SDK pinned; dry-run after every upgrade.
Uruguabot preview

Uruguabot

Verified Partner
Crypto Markets

Self-hosted Python bot for Polymarket's 5-minute BTC and ETH up/down markets, sold with its complete live trading record — losses included. A free GitHub repo publishes every fill from two generations of testing plus a 1,934-window study in which every automated signal scored roughly coin-flip against the human's 59%; the published numbers reproduce exactly from the raw CSVs, though the logs omit market ids, so the record is self-attested rather than on-chain verifiable. Both generations together lost about $270 — mostly execution and a since-fixed ghost-fill bug — while the configuration that ships as default closed its live run at +7.3% ROI on a 40% win rate over a small 25-trade sample: momentum entries, stop re-anchored to execution price minus 10¢, winners held to binary resolution. Dry-run is the default, with fills simulated from slippage measured on real trades; live mode takes two explicit flags and a dedicated wallet.

Bot
one-time
BTC 15-Min Bot
Open source · GitHub

BTC 15-Min Bot

Crypto Markets

Open-source Python bot for Polymarket's 15-minute Bitcoin up/down markets. A 7-phase engine fuses spike detection, Fear & Greed sentiment and cross-exchange divergence via weighted voting. Runs live or in paper mode with Grafana dashboards.

Bot
open-source
Poly-Maker
Open source · GitHub

Poly-Maker

Market Making

Open-source market-making bot for Polymarket. Quotes both sides of the book over WebSockets with configurable spreads, position merging and risk controls. Shared by its author as a reference implementation, not a turnkey money-maker.

Bot
open-source

Frequently asked questions

Can I run a Polymarket bot on my laptop?
For paper trading and development, yes. For anything with resting orders or open positions, no: a laptop that sleeps, updates or loses Wi-Fi leaves orders unmanaged in a moving market. A small VPS costs a few dollars a month and removes the single most common way hobby bots lose money.
Does server location matter?
For sniping and spot-lead strategies, yes — you are racing other bots to the book, and every hop counts. For market making, copy trading and news bots, a reliable VPS anywhere is fine; what matters there is uptime, reconnect logic and how you behave when data goes stale.
How should a bot handle a 429?
Stop sending, read Retry-After, wait that long, then resume — and treat the remaining-budget headers as a gauge, not a suggestion. Since July 2026 order placement and cancellation draw from per-signer token buckets on top of the per-IP limits; a bot that retries in a tight loop digs its own hole deeper.
What should wake me up at night?
A daily loss cap hit, a kill switch triggered, positions that do not match what the bot believes, a heartbeat that stopped, and a balance that changed when it should not have. Everything else is a morning email.