Server-Sent Events Disconnecting in Cursor Application
Your Cursor-generated application uses Server-Sent Events (SSE) for real-time updates (live notifications, streaming responses, dashboards), but the SSE connection drops after a few seconds or minutes. Users see the real-time feed freeze, and the browser's EventSource silently reconnects only to disconnect again in a loop.
SSE connections are long-lived HTTP connections that must stay open indefinitely. This conflicts with many infrastructure components that expect short request-response cycles. Reverse proxies, load balancers, serverless platforms, and CDNs all have default timeouts that terminate SSE connections prematurely.
The issue is often intermittent — it works fine during development where there's no proxy layer, but fails in production where Nginx, Cloudflare, or a serverless platform sits between the client and server.
Error Messages You Might See
Common Causes
- Reverse proxy timeout — Nginx, Apache, or Cloudflare terminates idle connections after 60-120 seconds by default
- Serverless function timeout — Vercel (30s), Netlify (26s), and Lambda (15min max) kill long-running functions, terminating the SSE stream
- No keep-alive heartbeat — Without periodic data sent on the connection, intermediaries assume it's dead and close it
- Missing SSE headers — The response lacks required headers like
Content-Type: text/event-stream,Cache-Control: no-cache, orConnection: keep-alive - Response buffering enabled — Nginx or Node.js response compression buffers SSE data instead of streaming it, causing events to arrive in batches or not at all
How to Fix It
- Send heartbeat comments every 15-30 seconds — Send SSE comment lines (
: heartbeat\n\n) at regular intervals to keep the connection alive through proxies and load balancers - Configure proxy timeouts — For Nginx: set
proxy_read_timeout 86400s;andproxy_buffering off;. For Cloudflare: enable WebSockets/SSE in the dashboard or use Cloudflare Tunnel - Disable response buffering — Add
X-Accel-Buffering: noheader for Nginx, and disable compression on SSE endpoints - Implement robust client reconnection — Use EventSource's built-in reconnection with a custom
retry:field, and includeLast-Event-IDhandling to resume from where the client left off - Avoid serverless for SSE — If your SSE needs long-lived connections, deploy on a traditional server (VPS, container) rather than serverless functions. Alternatively, use a managed service like Ably or Pusher
- Set correct response headers — Ensure every SSE endpoint sends:
Content-Type: text/event-stream,Cache-Control: no-cache,Connection: keep-alive
Real developers can help you.
You don't need to be technical. Just describe what's wrong and a verified developer will handle the rest.
Get HelpFrequently Asked Questions
Can I use SSE with serverless platforms like Vercel?
Standard SSE with long-lived connections doesn't work well with serverless platforms due to function execution time limits. Vercel supports streaming responses for up to 30 seconds. For longer connections, use a dedicated WebSocket service (Ably, Pusher, Supabase Realtime) or deploy the SSE endpoint on a traditional server.
How is SSE different from WebSockets?
SSE is unidirectional (server to client only), uses standard HTTP, and has built-in reconnection. WebSockets are bidirectional, use a separate protocol (ws://), and require manual reconnection logic. Use SSE when you only need server-to-client updates; use WebSockets when you need two-way communication.