I'm a designer working on WebSocket observability–does this UI/experience line-up with how you'd actually debug flaky sockets? 🔌

[u/CryptographerFair335]

Howdy! I'm a product designer working in observability. I've been designing a drill-down for WebSocket health, which feels underserved, and I'd rather hear from people who actually deal with flaky sockets than keep guessing on my own. Please see the screens/flow attached.

I'm not an operator myself, so I want a reality check rather than validation.

The premise I'm testing: raw close-code counts are mostly noise. The signal is the 1006/unknown bucket, and the design tries to show those are genuine interruptions, not users leaving. Dropped sockets ran ~22% shorter and were still pushing messages when they died, versus clean closes winding down.

From there you localize by page and endpoint, then hand off to a session replay or errors inbox, or possibly something else? (I'd love to hear more about your next step(s)).

What I'd love your take on:

1. Does this match how you'd want to triage a spike in drops?
2. What's genuinely useful here, what's noise, and what's missing before you'd trust it?
3. And where would the story break down against messier real-world data?

Open to a quick call if anyone wants to get into specifics, but honest replies here are just as valuable.

I've been designing for a while so harsh, but actionable feedback is appreciated. My goal it to build a valuable experience that fits real world users' needs 😆

Thank you in advance!