Operating
Practical notes for running a long-lived connection in production: how to resume after a drop, how the server keeps connections alive, and the limits to design around.
Reconnects (live-only)
This WebSocket is a live-only feed: it delivers blocks as they arrive and keeps no history for replay. On reconnect you simply resume the live stream — there is no server-side catch-up. Cursor handling stays internal to the server, so each stream resumes from its persisted cursor on restart and the live feed continues with no client action.
For historical data or to backfill a gap, use Substreams gRPC with an explicit start_block — it natively resumes from any block, cursor, or timestamp and is the right tool for replay.
Heartbeats
The server sends WebSocket ping frames every 180s. Standard clients pong automatically. Connections that don't pong within 600s are closed.
Limits
- Live-only. No replay or historical backfill. For history, use Substreams gRPC directly with a
start_block. - One output type. Only
sf.substreams.sink.database.v1.DatabaseChanges. - Per-connection buffer. Slow consumers are dropped per-message rather than blocking ingest (default 1024 messages). On recovery the server emits a
droppedlifecycle frame with thecountlost and where delivery resumed, so you can reconcile instead of silently shipping a hole. - Beta: per-key concurrency capped at 4 connections during the beta window.