The 'Realtime subscription failed' error in Supabase means the WebSocket connection for real-time data updates could not be established or was dropped. Common causes include the table not being added to the Realtime publication, RLS policies blocking the subscription, and incorrect Supabase client initialization. Enable Realtime for the table in the dashboard and verify RLS allows SELECT access.
What does "Realtime subscription failed" mean in Supabase?
When a Supabase Realtime subscription fails, the WebSocket connection that enables live data updates could not be established or maintain its connection. Supabase uses PostgreSQL's replication system to broadcast database changes to connected clients through WebSocket channels.
The most common cause is that the table is not added to the Realtime publication. By default, new tables in Supabase are not published to Realtime — you must explicitly enable it in the Dashboard (Database > Replication > select the table). Without this, subscriptions appear to connect but never receive any events.
RLS policies also apply to Realtime subscriptions. If the authenticated user does not have a SELECT policy for the table, the subscription will either fail or return no events. This is especially tricky because there is no explicit error — the subscription simply stops receiving updates.
Common causes
The table is not added
to the Supabase Realtime publication, so no change events are broadcast
RLS policies block the SELECT
operation, preventing the subscription from receiving row data
The Supabase client is initialized with
incorrect URL or anon key, preventing WebSocket connection
A browser extension or corporate
proxy blocks WebSocket connections on port 443
The subscription channel name or
table name has a typo that does not match any actual table
Too many concurrent Realtime connections
exceed the project's limit (default varies by plan)
How to fix "Realtime subscription failed" in Supabase
First, enable Realtime for the table. Go to the Supabase Dashboard > Database > Replication. Check the box next to the table you want to subscribe to. Alternatively, run SQL: ALTER PUBLICATION supabase_realtime ADD TABLE your_table_name;
Next, verify your RLS policies allow SELECT access for the subscribing user. Realtime uses the same RLS evaluation as regular queries. If the user cannot SELECT from the table, they will not receive Realtime events.
Check your Supabase client initialization. The client needs the correct project URL and anon key. Verify these in the Supabase Dashboard > Settings > API. For Lovable projects, these should be in the Cloud tab > Secrets.
Test the subscription in isolation. Create a simple subscription that logs all events to confirm the connection works before adding complex filtering logic.
If the subscription connects but receives no events, the table may not be in the publication. If it connects and immediately disconnects, check for WebSocket blocking by your network or browser extensions. Try in an incognito window to rule out extension interference.
// Table not in Realtime publication, no error handlingconst channel = supabase .channel('posts-changes') .on('postgres_changes', { event: '*', schema: 'public', table: 'posts' }, (payload) => console.log(payload) ) .subscribe();// First: enable Realtime in Dashboard or SQL:// ALTER PUBLICATION supabase_realtime ADD TABLE posts;const channel = supabase .channel('posts-changes') .on('postgres_changes', { event: '*', schema: 'public', table: 'posts' }, (payload) => { console.log('Change received:', payload.eventType, payload.new); } ) .subscribe((status) => { if (status === 'SUBSCRIBED') { console.log('Realtime subscription active'); } else if (status === 'CHANNEL_ERROR') { console.error('Subscription failed — check RLS and Realtime publication'); } else if (status === 'TIMED_OUT') { console.error('Subscription timed out — check network connection'); } });Prevention tips
- Always enable Realtime for the table in Dashboard > Database > Replication before creating subscriptions — this is the most commonly missed step
- Add a status callback to .subscribe() to detect connection failures, timeouts, and error states programmatically
- Verify that RLS SELECT policies allow the subscribing user to read from the table — Realtime follows the same RLS rules as regular queries
- Unsubscribe from channels when components unmount to prevent connection leaks and hitting concurrent connection limits
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
My Supabase Realtime subscription connects but never receives any events. The table has data and I can query it with .select(). What could prevent Realtime from broadcasting changes?
My Supabase Realtime subscription to the 'messages' table is not working. Here is my subscription code: [paste code]. Diagnose why I'm not receiving events and fix the setup.
Frequently asked questions
Why does my Supabase Realtime subscription not receive events?
The most common cause is that the table is not added to the Realtime publication. Go to Dashboard > Database > Replication and enable the table. Also verify that RLS SELECT policies allow the subscribing user to read the data.
How do I enable Realtime for a Supabase table?
In the Dashboard: go to Database > Replication and check the box next to your table. Or run SQL: ALTER PUBLICATION supabase_realtime ADD TABLE your_table_name; Both methods achieve the same result.
Do RLS policies affect Realtime subscriptions?
Yes. Realtime subscriptions follow the same RLS rules as regular queries. If the user does not have a SELECT policy for the table, they will not receive any Realtime events. There is no explicit error — the subscription simply returns no data.
How many concurrent Realtime connections can I have?
The limit depends on your Supabase plan. Free plans have lower limits. If you hit the limit, new subscriptions fail silently. Always unsubscribe from channels when components unmount to free up connections.
Can RapidDev help set up reliable Realtime subscriptions in Supabase?
Yes. RapidDev can configure Realtime publications, set up proper RLS policies for subscription access, implement connection monitoring, and build auto-reconnection logic for production applications that depend on real-time data.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your issue.
Book a free consultation