I work on OnePassApps, the team behind app.onepassapps.com. Everything below was measured on our own site on 10 November 2026, from the shell, with no session, no cookies and no JavaScript running.
We serve 56 pages and 79 asset files. I fetched every page once and every asset once, then counted strings in the bytes that came back. This is the layer that decides whether our site can push an update to you or only pull one.
The headline is an absence, and it is a clean one. The string ws:// appears 0 times and wss:// appears 0 times across all 56 pages and all 79 asset files, and sendBeacon appears 0 times as well. There is no socket address anywhere in the fleet. Nor is a connection ever opened: new WebSocket appears 0 times, WebSocket( appears 0 times, new EventSource appears 0 times and EventSource( appears 0 times.
Two of those counts are not zero, and both are a word in a list rather than a connection. WebSocket appears 2 times as text and EventSource appears 1 time, and every one of those occurrences is inside a single comma-separated list of 31 browser API names in one chunk: EventTarget at the front, XMLHttpRequestUpload at the end, WebSocket as name number 26 and EventSource as name number 9. The two WebSocket occurrences are the name itself and the front of the name next to it. Nothing in that list is ever called.
One more string could have been a push channel and is not: text/event-stream appears 1 time, in a list of three content types beside application/x-ndjson and application/stream+json, inside the code that measures streaming responses. It is a name to recognise, not a subscription.
So how does anything here update itself? With ordinary request and response, on a timer. fetch( appears 34 times, setInterval( appears 5 times and setTimeout( appears 78 times across the same bytes. The long repeating intervals are query refresh values - 20000 ms, 30000 ms - on the overview and runtime and workflows queries. The only timer of its own is one self-clearing poll in the index-CLafT-_V.js chunk, every 100 milliseconds, next to a timeout in the same helper.
One more thing I checked, because it looks like a background channel and is not. serviceWorker appears 4 times and navigator.serviceWorker 2 times, all of it in /assets/index-CLafT-_V.js, inside a helper that lists entries and deletes them. serviceWorker.register appears 0 times.
For a reader, the practical consequence is simple: every update our site shows you is a request your browser makes and can see, on a timer, and nothing stays open behind the page.
Limits, stated plainly: one build, one day, 10 November 2026, one IP, one region. These are counts of the bytes as they came back today. They say nothing about what any API returns, and I did not open either of our two hosted apps in this measurement. The asset list is the one the pages point at plus the lazy chunks the entry chunk names, so a chunk loaded only at runtime behind a feature flag would not appear in it.
Here is the site itself, if you want to look at it:
https://app.onepassapps.com/?utm_source=devto&utm_medium=post&utm_campaign=live-update-layer&utm_content=app-link
The guides, which spell out what each app needs:
https://app.onepassapps.com/guides?utm_source=devto&utm_medium=post&utm_campaign=live-update-layer&utm_content=guides-link
I work on OnePassApps - that is who we are, and this is our own site, measured by us.
Top comments (0)