Presence & HTTPS fallback
How the client reports liveness when WebSocket support varies.
Preferred transports#
| Client state | Presence path |
|---|---|
| Linked, telemetry acknowledged | Reuses the authenticated telemetry WebSocket. An HTTPS registration prepares the scoped fallback token. |
| Unlinked or relay not acknowledged | Can use the basic /runtime-presence/ws route, independent of dashboard linking. |
| WebSocket unavailable or unhealthy | Uses the HTTPS heartbeat fallback while retrying WebSocket with backoff. |
Basic presence is restricted to liveness. It cannot read stored snapshots or join an authenticated dashboard channel. Runtime and presence secrets are not placed in the socket URL.
Acknowledgements and retry#
The client expects an acknowledgement within five seconds. A missing acknowledgement enables fallback. Reconnect delay grows from five seconds to a maximum of five minutes and resets after an acknowledgement; callbacks from retired sockets are ignored.
The HTTPS heartbeat normally runs every 300 seconds. Failed HTTP attempts are spaced by at least 15 seconds. A local five-second watchdog is not a five-second network heartbeat.
Disconnect and stale online state#
Graceful stop waits up to two seconds for a WebSocket disconnect acknowledgement, then uses HTTPS fallback if needed. Socket close alone does not delete presence because the client may be changing transports.
Silent exits can remain online until the documented seven-minute stale window expires. Scheduled cleanup later removes inactive presence rows after the separate 15-minute retention threshold. These describe different stages.
Resource cost#
WebSocket upgrades, messages and Durable Object execution still use service resources. HTTPS fallback consumes requests. Using fewer recurring HTTP heartbeats is not a claim that presence is free or that a particular Cloudflare account cannot hit limits.