429 Too Many Requests on Realtime connections with Project Alerts

Question

Goal is to configure Supabase Project Alerts to signal real capacity issues without generating excessive notification noise, with particular attention to Realtime WebSocket behavior.

Project Alerts support thresholds for API usage, storage and database queries, but the dashboard does not expose fine-grained mute controls per metric. Evaluation is tied to a fixed 5-minute window without custom aggregation, and there is no documented auto-silence after manual acknowledgment. The alerting surface also lacks a REST API for programmatic suppression. The Realtime API documents a per-project connection limit and a 429 Too Many Requests response when the limit is exceeded, without clarifying whether the 429 is per-client or aggregated across all connections.

Is the 429 Too Many Requests response for Realtime emitted per client or aggregated across the project connection pool? Can a specific metric be muted or silenced within Project Alerts while keeping other metrics active? Is there a documented acknowledgment or suppression mechanism that prevents re-triggering on each evaluation window?

Tasadduq Burney · Answer

Direct Answer
The 429 Too Many Requests for Supabase Realtime is aggregated across the project‑wide WebSocket connection pool; it is not emitted per individual client.
Likely explanation
When the pool reaches its configured concurrent‑connection limit, new handshake attempts receive HTTP 429 while existing clients stay connected, so bursts of 429s appear for later clients until capacity frees.
Confirmed facts

Supabase enforces a single concurrent‑connection limit per project.
The 429 response is aggregated across the project pool, not per client.
Project Alerts can be enabled or disabled and their thresholds edited, but no per‑metric mute or snooze is documented.
Alerts evaluate on a fixed ~5‑minute interval with no custom aggregation window.
An active alert re‑fires on each evaluation window until the underlying condition changes or the alert is disabled.

Steps to verify

Open Project Settings → Alerts and note the available controls for each alert type.
In a test environment, gradually increase concurrent Realtime clients until new connections start returning 429 while existing clients remain connected.
Check the Realtime connection count in Project Settings → General and correlate timestamps of 429 responses with total active connections to confirm pool saturation.
Review the alert notification history to see if the same alert repeats on each 5‑minute window while the condition persists.

Missing diagnostic detail
Do you need to keep the alert active for other metrics while silencing this specific metric?

429 Too Many Requests on Realtime connections with Project Alerts

1 answer

Direct Answer

Likely explanation

Confirmed facts

Steps to verify

Missing diagnostic detail

Your perspective belongs here.

0 question comments