Rate Limit During Deploy

Symptom

A deployment attempt is rejected, and the UI shows a countdown timer indicating when you can deploy again. The API returns HTTP 429 (Too Many Requests). This commonly occurs during rapid iteration with auto-deploy enabled.

Likely Causes

1. Staging deploy rate limit exceeded: You triggered more than 20 manual staging deployments within 5 minutes.
2. Production deploy rate limit exceeded: You triggered more than 10 production deployments within 5 minutes.
3. Auto-deploy rate limit exceeded: Auto-deploy triggered more than 60 staging deployments within 1 minute due to rapid sequential saves.
4. Multiple tabs or users deploying: Several browser tabs or team members are deploying to the same project simultaneously, consuming the rate limit faster.

Checks

1. Check the deploy panel for the countdown timer. The timer shows the remaining seconds until you can deploy again.
2. Check whether auto-deploy is enabled. With auto-deploy on, every save triggers a staging deploy. Rapid saves (e.g., Cmd+S in quick succession) can exhaust the limit.
3. Check how many deployments were made recently. The version history panel shows recent deployments with timestamps.
4. If other team members have editor access, check whether they are also deploying.

Fixes

Wait for the cooldown

The rate limit resets after the window expires:

The countdown timer in the deploy panel shows exactly when you can deploy again. Wait for it to reach zero, then retry.

Reduce deploy frequency

• Batch your changes: Make multiple edits before saving and deploying, rather than saving after each small change.
• Disable auto-deploy during heavy editing: Turn off auto-deploy, make your changes, then deploy manually when ready. Re-enable auto-deploy afterward.
• Use Cmd+Alt+S to save all: Save all files at once rather than saving individual files one at a time (which triggers an auto-deploy per save).

Coordinate with team members

If multiple team members are deploying, establish a workflow where one person handles deployment during active development sessions.

How Rate Limits Work

Rate limits are enforced per IP per endpoint. Deploy rate limits use a per-project-per-IP bucket. The server tracks request counts within a rolling time window. When the count exceeds the limit, subsequent requests receive HTTP 429 until the window resets.

When a deploy is rate-limited, the server returns 429 and the client retries with exponential backoff. The UI shows a countdown timer indicating when the next attempt will be made.

Rate limits reference

See Plans and Limits for the full rate limits table.

Related

• Deployment Lock Contention for 409 errors (lock conflict, not rate limit).
• Auto-Deploy and Live Reload for controlling auto-deploy behavior.

What to Capture for Escalation

1. The HTTP status code (429) and response headers (look for Retry-After or rate limit headers).
2. The deployment type (manual or auto-deploy).
3. Approximate number of deploys in the last 5 minutes.
4. Whether auto-deploy is enabled.
5. Whether multiple users or tabs are deploying to the same project.