Rate limiting

Where limits show up

Logging touches three places. Clients send to your game server over a RemoteEvent (no API key, no HTTP). The server sends batches to Flux over HttpService. Flux applies your plan's per-minute cap on the API.

Each step has its own throttle so one noisy client or a log spam loop does not burn your whole HTTP budget.

HttpService on the game server

Roblox gives you about 500 HTTP requests per minute per server. Blow past that and HttpService can freeze for ~30 seconds. Only FluxServer makes HTTP calls. Never LocalScripts.

The server worker keeps a queue (up to SERVER_QUEUE_MAX, 800 logs). It POSTs up to SERVER_HTTP_BATCH_SIZE (100) logs at a time and waits between requests so you stay around SERVER_HTTP_REQUESTS_PER_MINUTE(100/min), well under Roblox's cap. In practice that is up to ~10,000 logs per minute per server if the queue stays full.

If the queue fills up, Flux drops lower-priority logs first: client info, then server info, then client warn, and so on. Server errors are kept longer, and logs flagged via Security()are kept the longest of all — exploit evidence is the last thing dropped. Failed HTTP batches go back on the queue and retry with backoff (up to 30s).

You need Allow HTTP Requests on in Studio. See HTTP in Studio.

Client logs before HTTP

FluxClient holds logs for a short moment (about 150ms by default) and sends them in chunks of up to MAX_REMOTE_PACKET_LOGS (100) over FluxRemoteEvent.

On the server, each player can only push PLAYER_CLIENT_LOG_MAX_PER_WINDOW (200) client logs every PLAYER_CLIENT_LOG_WINDOW_SEC (10) seconds. After that, extra packets are dropped and you get a warning in the output. That keeps one exploiter from flooding your HTTP queue.

Flux API (your plan)

Flux counts logs, not HTTP requests. Send 100 logs in one batch and that uses 100 of your minute's allowance.

• Free: 100 logs / minute / project
• Pro: 5000 logs / minute / project
• Studio: 20000 logs / minute / project

The counter resets each UTC minute. Go over the limit and you get 429 with INGEST_RATE_LIMIT. The SDK treats that like any other failed batch and retries later.

If you are hitting limits

Do not log inside tight loops or every frame as info. One error with a good message beats fifty info logs. Labels and payloads let you say more in fewer calls.

FluxServer.Ping() uses HttpService on a background thread. Run it once to test connectivity, not on a timer. If client traffic is heavy, try a slower flush: set clientFlushMs = 200 in FluxConfig (50 to 500 ms allowed).