It's crazy that in 2024, the state of the art way to debug a reported issue is to hop on a call. How is there no tooling?!
So we built a tool we needed back at Cloudflare: fast forward to today and it's used by 150k people all over the world.
But it still only solved when PMs or QA reported bugs to engineers. We still hadn't quite figured out how to help users –– usually the worst bug reporters of them all –– report bugs better.
There are tools out there for session recording, but then to find the exact moment you need, you need to scrub through a 45 min video of someone's entire session. It's 1) creepy 2) not efficient.
So we kept thinking.
Earlier this year, an engineer on our team prototyped something we could use in our own customer support chats. It's a plugin that lets support agents request a screen recording (with dev logs) from the customer.
As we started to use it ourselves, we realized it was saving us from having to hop on calls with customers and ask them a lot of questions to figure out what was happening.
While recording, we automatically capture:
- Console logs
- Network requests (fully inspectable, w/ copy as cURL for local repro)
- Timing waterfall
- Session metadata (User ID, etc) & system status (battery, etc)
- Device/browser/OS info
There’s some extra debug tooling in there for websockets and graphql too (we love/hate graphql, but that’s besides the point.)
You can see an example of what the captured data looks like here: https://jam.dev/c/cff872c4-0a40-4bc2-a35a-9623cc4926a6
It’s a lot more private than the session recording tools out there because it’s only recording when the user explicitly starts/stops the recording, and not the full session.
I hope you’ll check it out and let us know what you think: jam.dev/customer-support
The worst part of debugging customer issues is not even the debugging, it’s just figuring out what the user is even talking about. It’s so crazy that there’s not much tooling out there to make that a lot faster, even in 2024. We really want to build something that makes this part of the job suck less, and we'd love to know what you think and how we can make it even better.
My email is dani@jam.dev, feel free to reach out anytime.
By the way, we’re hiring engineers and if making debugging a lot more efficient is a problem that excites you, we’d love to chat: jam.dev/careers
No comments yet.
