Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years
239 comments
Nice work, looks like you've got some big names using it too, congrats.
I have some feedback on your homepage & messaging.
Initially scrolling the home page I thought it was a tool for viewing customer bug sessions, similar to TrackJS or Sentry.
Reading this post it became clear this is for product managers and/or team members to file bugs. The line "Built for everyone" on the home page threw me off.
I think if you make the distinction that this is an internal tool for teams vs. an external tool for tracking customer issues it might help make this messaging clearer.
I'm not sure of your plans (perhaps you also intend for external users to use it) this was just my first pass impression.
I think this is a great tool. The structured format combined with the information provided by the extension are what make it valuable to me. The last minute feature is also nice as re-creating bugs can be a PITA.
As a dev, I would ideally also want to be able to view stack traces with source maps, but having a consistent structured format combined with the extension data is enough of a value prop to start using it.
I have some feedback on your homepage & messaging.
Initially scrolling the home page I thought it was a tool for viewing customer bug sessions, similar to TrackJS or Sentry.
Reading this post it became clear this is for product managers and/or team members to file bugs. The line "Built for everyone" on the home page threw me off.
I think if you make the distinction that this is an internal tool for teams vs. an external tool for tracking customer issues it might help make this messaging clearer.
I'm not sure of your plans (perhaps you also intend for external users to use it) this was just my first pass impression.
I think this is a great tool. The structured format combined with the information provided by the extension are what make it valuable to me. The last minute feature is also nice as re-creating bugs can be a PITA.
As a dev, I would ideally also want to be able to view stack traces with source maps, but having a consistent structured format combined with the extension data is enough of a value prop to start using it.
I agree with your comment on messaging, that is fantastic feedback–– reading through the comments here in the HN thread, it seems like that's a common understanding from our landing page. I appreciate you flagging that, we should find better wording to make it more clear.
And that's really nice to hear, thank you so much! Stack traces with source maps. I agree. We integrate now with logging tools like Sentry and I wonder if we can just use sourcemaps from that.
And that's really nice to hear, thank you so much! Stack traces with source maps. I agree. We integrate now with logging tools like Sentry and I wonder if we can just use sourcemaps from that.
Built for product managers who want quick bug fixes and engineers who want clear and reproducible bug reports.
It's NOT built for everyone.
Right?
It's NOT built for everyone.
Right?
I got the same impression at first. Then I saw the drawing tools and I thought that’s a lot to ask from end users. Messaging is confusing for sure.
I got really excited before I saw there was no firefox support. Thats a deal breaker for my team :(
I really like this idea and if Firefox support was added I would purchase it in a heartbeat.
I really like this idea and if Firefox support was added I would purchase it in a heartbeat.
[I work at Jam] We do have an internal build for Firefox.. it's coming :)
It would be great to have a FAQ page on your site mentioning this. I was on your docs page and did a search for "firefox" as well as "safari" in the search box and there were no hits at all. Seems like something that people would often be checking for.
Great feedback, that would definitely be a good thing to add!
Love this tool, want to buy it for our team. Unfortunately, a tool that doesn't support Safari can't readily be used to help iterate products that use default browser or webkit webviews on MacOS or iOS.
We've noticed many tool devs think everyone uses Chrome (because those devs got non tech people in their social circle to install Chrome so "everyone they know" uses Chrome), but users who don't know devs just use whatever's there, and that means iPad, iPhone, and most Mac "end users" are Safari.
Along with being needed for those users, any tool that looks this good and works this magically is also going to appeal to dev teams that can appreciate why users like iPhones and designers like Macs, those teams will want this to work in Safari too.
That said, if you couldn't readily support Safari, I wonder if your extension could be adapted to work in Kagi's Orion browser that supports Chrome and Firefox extensions (to an extent), while being based on WebKit. Perhaps that's a path that could allow webkit debugging.
We would definitely pay for a Safari extension to be installed from Apple app store for each of our UX devs, product managers, and canary users.
For enterprise deployment, it needs to come from Apple app store or be distributed as an installable package through an automation mechanism. MAS (Mac app store) is easiest.
The extension needs to either be free, or have a "full price" version, so that it can be licensed per seat/user through corporate volume purchasing to run on employee devices. The way managed devices work, there's no way for companies to pay for employees to use in-app purchases (IAP).
We've noticed many tool devs think everyone uses Chrome (because those devs got non tech people in their social circle to install Chrome so "everyone they know" uses Chrome), but users who don't know devs just use whatever's there, and that means iPad, iPhone, and most Mac "end users" are Safari.
Along with being needed for those users, any tool that looks this good and works this magically is also going to appeal to dev teams that can appreciate why users like iPhones and designers like Macs, those teams will want this to work in Safari too.
That said, if you couldn't readily support Safari, I wonder if your extension could be adapted to work in Kagi's Orion browser that supports Chrome and Firefox extensions (to an extent), while being based on WebKit. Perhaps that's a path that could allow webkit debugging.
We would definitely pay for a Safari extension to be installed from Apple app store for each of our UX devs, product managers, and canary users.
For enterprise deployment, it needs to come from Apple app store or be distributed as an installable package through an automation mechanism. MAS (Mac app store) is easiest.
The extension needs to either be free, or have a "full price" version, so that it can be licensed per seat/user through corporate volume purchasing to run on employee devices. The way managed devices work, there's no way for companies to pay for employees to use in-app purchases (IAP).
Awesome, I will check back regularly.
This looks like one of those tools that is genuinely really useful. I would love be able to tell my users to just fireup a browser extension and record a bug, rather than having to step them through how to capture all that data manually.
Well Done!
Bookmarking this page for the futuere: https://jam.dev/docs/downloads-and-browsers/browser-support
This looks like one of those tools that is genuinely really useful. I would love be able to tell my users to just fireup a browser extension and record a bug, rather than having to step them through how to capture all that data manually.
Well Done!
Bookmarking this page for the futuere: https://jam.dev/docs/downloads-and-browsers/browser-support
That’s so amazing to hear, thanks for the kind words
[deleted]
How about Safari? This would be very useful as not every developer has Apple hardware
Orion could make this easier
- basically a Safari fork with Chrome / FF plugin support (use it as my daily driver, pretty good and uBlock Origin in Safari? Yes please!)
Consumer facing stuff so nobody in my use case is running much other than a few versions of Safari or Chrome on desktop or really Safari on mobile. (87-92% iOS on mobile)
Yeah sure but this is tool for internal use
Agree, it's a debugging tool for what users see, and users see your app on WebKit in Safari.
So agree, the PdM should not be using Chrome.
I suggested the Kagi Orion path elsewhere in this comment page too, since that would give the PdM extensions, while still seeing what users see.
So agree, the PdM should not be using Chrome.
I suggested the Kagi Orion path elsewhere in this comment page too, since that would give the PdM extensions, while still seeing what users see.
Man. It will literally never stop being funny to me when people try guilt-tripping developers into adding Safari support. It's the exact same shtick, every single time:
"Can we have Firefox support? It would really help promote the Open Web."
"Sure, it was on our roadmap already."
"AKTLY You need to rewrite your app for Safari support and WebKit coverage because if you ignore that then imagine how bad the iOS experience will be!!! People will blame you instead of themselves because they're simply too domesticated to fix technology issues, so do their work for them!"
...rinse and repeat for everything Apple refuses to support themselves. We wouldn't be begging people for Safari support if it was a successful browser or if people actually cared about it in the first place.
"Can we have Firefox support? It would really help promote the Open Web."
"Sure, it was on our roadmap already."
"AKTLY You need to rewrite your app for Safari support and WebKit coverage because if you ignore that then imagine how bad the iOS experience will be!!! People will blame you instead of themselves because they're simply too domesticated to fix technology issues, so do their work for them!"
...rinse and repeat for everything Apple refuses to support themselves. We wouldn't be begging people for Safari support if it was a successful browser or if people actually cared about it in the first place.
Millions of people use Safari all day every day.
Developers might not like it but people use it. Personally I use it for almost everything now.
Developers might not like it but people use it. Personally I use it for almost everything now.
But with a fork of WebKit? I don’t think another fork is all that helpful in the context of trying to fix a bug.
It's not a fork of WebKit. It uses WebKit.
https://blog.kagi.com/orion-features
https://blog.kagi.com/orion-new-features
https://blog.kagi.com/orion-features
https://blog.kagi.com/orion-new-features
Ahhh.
Someone said Safari fork but not WebKit fork.
https://news.ycombinator.com/item?id=40323838
Someone said Safari fork but not WebKit fork.
https://news.ycombinator.com/item?id=40323838
Yes! Safari is also on the roadmap.
That’s good to hear. I haven’t used Chrome since Firebug was released.
Professionally I do all of my development in Firefox and only occasionally check that Chrome works
It seems pretty bold move when you consider that V8-based browsers covers 75.5% of the market [1].
[1]: https://gs.statcounter.com/browser-market-share
[1]: https://gs.statcounter.com/browser-market-share
How is it a bold move? If it works in Firefox it’s much more likely to work in other browsers, whereas if it works in Chrome it might or might not work elsewhere. I switched to Firefox as my default for development years ago because I got fed up of wasting time on issues because something would work in Chrome but not work in one or more other browsers. Using Firefox saves me time and effort so there’s nothing bold about it, purely pragmatic.
I haven’t caused any Chrome issues with this as far as I know. And I’ve built apps with hundreds of thousands of MAUs.
> but the important information the engineer needed was what was actually right outside the boundary of the screenshot I took
Ah ah. At one gig we had trained the users to always send a screenshot of the entire screen. People reviewing the tickets would dump them if the screenshot was cropped and the user warned: "No full screenshot, no ticket".
Why? The most important info was the time at which the error happened (which, for users who were on Windows, was in the bottom right of the screen).
With the time we could look in the logs and the error/bug was usually obvious.
Ah ah. At one gig we had trained the users to always send a screenshot of the entire screen. People reviewing the tickets would dump them if the screenshot was cropped and the user warned: "No full screenshot, no ticket".
Why? The most important info was the time at which the error happened (which, for users who were on Windows, was in the bottom right of the screen).
With the time we could look in the logs and the error/bug was usually obvious.
This seems like it would only work if the applications in question didn't contain any PII - as soon as you get into applications or flows within an application that contain some form of PII, either displayed or the user entering it, having them send a screenshot of the entire screen is asking for the user to accidentally leak their PII to the person reviewing the ticket.
Where I work (in which the above would be a problem), we make sure to log enough information that given a relative timeframe of when the user had the issue, we can usually narrow down to where the issue was using context and some querying of the logs (splunk is incredibly helpful for this)
Where I work (in which the above would be a problem), we make sure to log enough information that given a relative timeframe of when the user had the issue, we can usually narrow down to where the issue was using context and some querying of the logs (splunk is incredibly helpful for this)
Indeed, that's a great rule. Another one is "What URL was the browser on?" which is rarely ever in cropped screenshots but is visible in full screenshot
Don’t many browsers hide the full URL now?
Oh maybe, I do remember hearing about that. Mine don't (Firefox & Chrome on Fedora) but maybe that's a default setting (on Linux) or maybe I changed the setting and forgot about it?
I think you changed it immediately when you first saw it and never thought about it again. I’d doubt Chrome binaries on any platform would change that only on one platform.
Desktop Chrome only hides the scheme by default I think.
URL, totally. I was talking to a PM recently where their customers self-host their product so without knowing the url, they have no idea where on the internet to start looking for the bug.
For us it's not the time but the id of the thing they're working on, but users tend to like to crop to just the dialog or subsection they're having issues with.
It's infinitely easier to help the customer when we can take our own look at things.
Good tip, will pass it along to support and see what they say.
It's infinitely easier to help the customer when we can take our own look at things.
Good tip, will pass it along to support and see what they say.
Seems nice but I hate sharing my whole browser window with anyone. I don't care to let other people see which plugins I use or my bookmarks toolbar etc.
> Why? The most important info was the time at which the error happened (which, for users who were on Windows, was in the bottom right of the screen).
Except it isn't in UTC and it doesn't show an offset.
Even if you stored the user's timezone, that doesn't mean that's where they were working from.
Except it isn't in UTC and it doesn't show an offset.
Even if you stored the user's timezone, that doesn't mean that's where they were working from.
oooh. you got them.
Like figuring out which timezone the user was in is impossible.
What if the user intentionally set their clock wrong to mess with support.
You are being silly.
You are being silly.
No, the people requiring a screenshot to include the time instead of just asking the user for an ID and time of error are the ones being silly. Have you ever heard of log filtering?
Or, some users might have hidden the taskbar, or the clock. Or have several screens, and only one of them has the clock...
Users that might customise their system a bit by digging into the settings are usually more inclined to give a detailed report in case they encounter a bug or have a general knowledge of what to look for when requested for some information in my team's experience. Sounds much more like an edge case.
True, but if the policy is to reject all cut screenshots... I'd rather add an "unless the ticket contains all the relevant information".
Most users don't customize anything, even something as trivial as that. Most corporate users may not be allowed to. I bet they never had to deal with any of these supposed gotchas.
The user not being in the time zone we expected has been exactly the information we were missing to debug something more than once. “The logs say it was 10am but the screenshot says 11… what if we were mishandling timezones?”
Ha! Right, totally!
That’s a great trick to get the exact time from full screenshot
That’s a great trick to get the exact time from full screenshot
Had a quick look. Seems like an interesting tool. I know there are many companies in Europe that, for regulations and compliance reasons, cannot have their data leave Europe. As far as I can see from the documentation, the data is stored in the US. Would be nice to have an option to store the data in Europe. Or not having to upload any data at all. But instead have the option export an artifact that can be processed later. But perhaps that defeats the business.
I am building a version of this that lets you store the data on your computer, you can export it and send it to your team (manually) so you can use any data hosting you want. Let me know if you're interested!
I'd also be interested, at least for internal bug reports and such. From what I can see, jam.dev is collecting what I collect for dev-teams anyhow, just faster and more comprehensive.
But this would possibly move customer data in requests and screenshots out of our control, and the entire hassle of adding subcontractors and managing order data processing agreements have taken quite a few good monitoring and debugging tools out of discussions, sadly.
But this would possibly move customer data in requests and screenshots out of our control, and the entire hassle of adding subcontractors and managing order data processing agreements have taken quite a few good monitoring and debugging tools out of discussions, sadly.
check it out at dashcam(dot)io - if you want to talk im at orlando at the same domain
From https://jam.dev/docs:
Jam is a browser extension that allows you to create the perfect bug report in just one click. You will now be able to capture an instant replay of the bug happening on your web app and include all the developer logs required to cut your bug reporting time by 20x.
(to me that was a more useful summary)
Jam is a browser extension that allows you to create the perfect bug report in just one click. You will now be able to capture an instant replay of the bug happening on your web app and include all the developer logs required to cut your bug reporting time by 20x.
(to me that was a more useful summary)
Thanks this wasnt clear after visiting their homepage
JUST in time for me man thank you. I'm going to try it.
Our company has just grown to where it isn't just some engineers and a few sales guys. Now we're trying to keep engineers working efficiently. / accurately, and the support team is ramping up. Making it easy for the sales or support guys to log a good ticket or bug is a never ending challenge. This looks like a great option.
I worked in support for ages and later moved to an engineering role, it's a mountain to climb to get good communication / reproducing things accurately enough for the engineers to really take action effectively.
Our company has just grown to where it isn't just some engineers and a few sales guys. Now we're trying to keep engineers working efficiently. / accurately, and the support team is ramping up. Making it easy for the sales or support guys to log a good ticket or bug is a never ending challenge. This looks like a great option.
I worked in support for ages and later moved to an engineering role, it's a mountain to climb to get good communication / reproducing things accurately enough for the engineers to really take action effectively.
That is really awesome to hear. Thank you for such a nice message!
+1 –– when I worked at Cloudflare, the support team had to teach all of us how to export HAR files from our browsers for engineers. It's definitely a mountain to climb to get good bug reporting working internally.
+1 –– when I worked at Cloudflare, the support team had to teach all of us how to export HAR files from our browsers for engineers. It's definitely a mountain to climb to get good bug reporting working internally.
[deleted]
I love the look of this tool and will be recommending our QA team take a look. However, I would like to encourage you to make SSO free and available to everyone. Better security should be a focus for everyone, not just those on an "Enterprise" plan. Tailscale recently had a great blog post about their SSO tax journey[0]. Please don't get added to the SSO Wall Of Shame[1].
[0] https://tailscale.com/blog/sso-tax-cut
[1] https://sso.tax/
[0] https://tailscale.com/blog/sso-tax-cut
[1] https://sso.tax/
Great feedback, thank you!
Our philosophy on pricing is to try and only make what real companies who can pay need, and offer what individuals and hobbyists and small startups need for for free, so that’s why SSO ended up a paid feature. But it’s great feedback for us - thank you!
Our philosophy on pricing is to try and only make what real companies who can pay need, and offer what individuals and hobbyists and small startups need for for free, so that’s why SSO ended up a paid feature. But it’s great feedback for us - thank you!
The benefits of SSO kick in way faster than you'd think, in some cases before you even have a company, much less revenue. I could easily see a Hackerspace wanting SSO, for example, and adding an SSO tax of fifty dollars a month would double membership costs. Then there's stuff like https://twitter.com/NireBryce/status/1564100084652036096.
"network tab" isn't it a security concern to record API calls?
Also how future proof it is with Google changing Chrome addons permissions / API etc...?
Also how future proof it is with Google changing Chrome addons permissions / API etc...?
Great concern!
We do two things to address that:
The first is nothing gets recorded and saved (or even sent to our backend) until the user actively chooses to log a bug. So it’s like actively choosing to save a HAR file when there’s a bug.
The second is we scrub all network requests on the client side for anything that resembles PII or sensitive data. We just don’t want it on our servers.
Is there anything else you think we should do?
Definitely building on the Chrome platform there’s always API risk of something changing but I hope Chrome and other browsers will keep it possible to provide a better debugging experience through extensions like ours for people who want it.
We do two things to address that:
The first is nothing gets recorded and saved (or even sent to our backend) until the user actively chooses to log a bug. So it’s like actively choosing to save a HAR file when there’s a bug.
The second is we scrub all network requests on the client side for anything that resembles PII or sensitive data. We just don’t want it on our servers.
Is there anything else you think we should do?
Definitely building on the Chrome platform there’s always API risk of something changing but I hope Chrome and other browsers will keep it possible to provide a better debugging experience through extensions like ours for people who want it.
Some kind of end-to-end team encryption would be great, I could generate a local passphrase using 1Password or something and put it in the team vault. Then you wouldn't have access to the request metadata (maybe outside of hostnames?) on your servers. Alternatively, an option to simply download local replays and then a desktop/electron viewing client instead of having to upload them to a server would be great too
I like that idea a lot, we should do that
I see in the Security page [0] that you filter out headers that you think are PII or tokens. And I see that you're willing to receive feedback via email. I don't think this approach is scalable, for the main reason that sometimes we use custom headers to pass tokens.
My suggestion is to have a setting that lists default headers you think should be obfuscated, and the user/team can remove and add to them as they like.
0. https://jam.dev/docs/product-features/dev-tools/security
My suggestion is to have a setting that lists default headers you think should be obfuscated, and the user/team can remove and add to them as they like.
0. https://jam.dev/docs/product-features/dev-tools/security
Maybe scrub cookies and authorization headers by default, but make them an opt-in for bugs where they're relevant?
Edit: it looks like this is already the case!
Edit: it looks like this is already the case!
> but make them an opt-in for bugs where they're relevant?
The tool seems to be built for people who don't know what to include in a proper bug report (As they are maybe not technical enough), so not sure how helpful that choice would be for them.
The tool seems to be built for people who don't know what to include in a proper bug report (As they are maybe not technical enough), so not sure how helpful that choice would be for them.
This might be a feature fit for the pro tiers. I would really like it for our QA testers who'd want to include that information but still aren't that technical to know all the places to look for that information.
[deleted]
Also ex-Cloudflare, have been following Jam for awhile, great product!
Something I would love is a way for customers to use this without having to install a Chrome extension. It would make debugging customer issues much faster - for example, if clicking 'Report a bug' on a website automatically triggered the recording flow and asked the user to reproduce it.
Something I would love is a way for customers to use this without having to install a Chrome extension. It would make debugging customer issues much faster - for example, if clicking 'Report a bug' on a website automatically triggered the recording flow and asked the user to reproduce it.
+1 on this request.
Would also like to be able to kick a report off automatically -- eg, on any exception or on any 4XX from the server.
Would also like to be able to kick a report off automatically -- eg, on any exception or on any 4XX from the server.
Stay tuned! We’re building this out soon. :)
Hello! Would love to learn more! Can you send me a note at [email protected]?
Nice! I remember when this tool launched and I checked it out. It's really nice to use with easy to setup integrations. The instant replay feature especially is super cool! My biggest request would be to please add a Firefox extension!
The Jam team seems like a talented and good group of people. I applied a while back and while I was turned down I got an actual human response from the team. They also did a push to ask for input on improvements for Jam maybe a year ago and offered to donate $25 (iirc) to St Judes for every person who responded.
The Jam team seems like a talented and good group of people. I applied a while back and while I was turned down I got an actual human response from the team. They also did a push to ask for input on improvements for Jam maybe a year ago and offered to donate $25 (iirc) to St Judes for every person who responded.
Thank you so much!! And so kind of you to say, you just made my day.
Firefox version - totally agree. We have to do it. I promise we will :)
Firefox version - totally agree. We have to do it. I promise we will :)
This looks really cool! Someone who worked adjacent to S2 (Cloudflare's remote browser isolation product) told me this would be a good idea to use BrowserBox for this reproducible bug replays around 2 years back. But I didn't have any other input that said the same so we didn't pursue it.
I think I could probably build a competitor to this that doesn't require a chrome extension, using BrowserBox. We already have web DevTools (just right-click or context-click the screen in): https://browse.cloudtabs.net/signupless_sessions and can record the screen output.
But I think hard to replicate will be your first mover advantage, client list, and bunch of other features and integrations. It's interesting you got it to such a state of readiness and polish before posting. Is that about acknowledging the replicability of the tech so you want to protect against that? Or customer requests? Or maybe more just team bias towards products of extreme beauty! :)
Congratulations on this successful launch! I look forward to exploring ways we might be able to collaborate on a web version (that also works on mobile etc, using BrowserBox/CloudTabs!!!).
I think I could probably build a competitor to this that doesn't require a chrome extension, using BrowserBox. We already have web DevTools (just right-click or context-click the screen in): https://browse.cloudtabs.net/signupless_sessions and can record the screen output.
But I think hard to replicate will be your first mover advantage, client list, and bunch of other features and integrations. It's interesting you got it to such a state of readiness and polish before posting. Is that about acknowledging the replicability of the tech so you want to protect against that? Or customer requests? Or maybe more just team bias towards products of extreme beauty! :)
Congratulations on this successful launch! I look forward to exploring ways we might be able to collaborate on a web version (that also works on mobile etc, using BrowserBox/CloudTabs!!!).
> It prevents product managers (like I used to be) from being able to create vague and un-reproducible bug tickets (like I used to create).
> ... Like, sometimes I thought I included a screenshot, but the important information the engineer needed was what was actually right outside the boundary... Or I'd write that something "didn't work" but the engineer wasn't sure if I meant that it returned an error or if it was unresponsive...
> ...the way we capture and report bugs is just as manual and lossy as it was in the 1990’s
That's because bug reports are primarily communication among people, and the problems you describe are people problems, not technology problems.
Bug reports work when engineering can state what they need, and management is willing to support engineering's needs. Otherwise, bug reports devolve into the situation that you describe above.
In your case, this looks like a great tool for browser applications; but it only works if the people submitting the bug use the tool: I could easily envision a situation where a lousy manager ignores engineering's pleas to use Jam.
> ... Like, sometimes I thought I included a screenshot, but the important information the engineer needed was what was actually right outside the boundary... Or I'd write that something "didn't work" but the engineer wasn't sure if I meant that it returned an error or if it was unresponsive...
> ...the way we capture and report bugs is just as manual and lossy as it was in the 1990’s
That's because bug reports are primarily communication among people, and the problems you describe are people problems, not technology problems.
Bug reports work when engineering can state what they need, and management is willing to support engineering's needs. Otherwise, bug reports devolve into the situation that you describe above.
In your case, this looks like a great tool for browser applications; but it only works if the people submitting the bug use the tool: I could easily envision a situation where a lousy manager ignores engineering's pleas to use Jam.
*engineers I work with are telling me that some of you are going to argue that types don’t exist in real javascript and that web assembly isn’t assembly
Well it's bytecode, so if you consider java or dot net bytecode assembly then it's assembly, if not then not. If we want to be pedantic, assembly is usually defined as being close to the architecture machine code, which web assembly is not.
Yeah, I fell into that trap, but it's a holiday here.
Yeah, I fell into that trap, but it's a holiday here.
Haha I knew this would happen!
I'm on holiday so I'll have a go and join the pedantic train. It's not as you say close to the hardware so it's intermediate code. And nobody argues .Net IL is assembly.
A lot of people get confused by assembly in WASM unfortunately, which leads them to claim that it is performant and if it's not, then fixing it is a trivial exercise of just making a fast WASM JIT compiler. Where did I hear this before?
They really should have gone for JSVM IR or something, but that would sell it to no one.
They really should have gone for JSVM IR or something, but that would sell it to no one.
I built a similar tool in 2016 called Bugcam that does exactly this. It was also a chrome extension with the ability to tie console logs and network traffic to screenrecordings. Jam looks really polished and far more usable than the weekend hack I put together :) Well done!
The explanation for why OP built Jam was precisely the motivation I had for building Bugcam. I had transitioned to a team in Europe as part of an acquisition that had non-technical PMs filing bug reports. Their reports were completely nondescript and incredibly frustrating to decipher and repro.
I ended up abandoning the project due to other opportunities that came up. One interesting thing I noticed was that a significant percentage of users downloaded Bugcam to record themselves playing games for YouTube. Perhaps there was another opportunity there, but I decided not to pursue it.
Congrats on the product and best of luck Jam team!
The explanation for why OP built Jam was precisely the motivation I had for building Bugcam. I had transitioned to a team in Europe as part of an acquisition that had non-technical PMs filing bug reports. Their reports were completely nondescript and incredibly frustrating to decipher and repro.
I ended up abandoning the project due to other opportunities that came up. One interesting thing I noticed was that a significant percentage of users downloaded Bugcam to record themselves playing games for YouTube. Perhaps there was another opportunity there, but I decided not to pursue it.
Congrats on the product and best of luck Jam team!
[I work at Jam]
Thank you for the kind words, Matt! If you ever want to go back to that world, shoot me an email at [email protected]. We are always hiring!
Thank you for the kind words, Matt! If you ever want to go back to that world, shoot me an email at [email protected]. We are always hiring!
Thank you Matt! That’s so cool. Like minds :)
I've been playing with this for a few hours and had similar questions about scrubbing custom tokens or headers from the submitted data.
One concern I have about the instant-replay feature is the potential performance implications when monitoring multiple tabs or windows. I'm not particularly fond of the idea of all sites in this way and prefer better controls there.
I saw the block list inside the extension, but I think an allow list makes more sense for this use case. That way, .ycombinator.com or .example could work as opt-in for instant replay, and ideally, those domains could be preconfigured at the team level.
Acknowledging Chrome's extension per-site permissions is a valid option, but it's clunky.
+1 vote for a datadog integration, in addition to backend data I would love to see this work well with RUM. For now, I'll settle for jamming a common ID into Jam.Metadata and see how that works out.
I also thought Jam would accept bug reports from end-users and look forward to the development of that feature.
Comments synced to timestamps in the recordings are nice. Have you considered a scribble/annotation like the still screenshots, but for videos? The annotations could be anchored to the comment timestamp, and they would help capture a UX micro-interactions that may not be obvious in a still or video.
One concern I have about the instant-replay feature is the potential performance implications when monitoring multiple tabs or windows. I'm not particularly fond of the idea of all sites in this way and prefer better controls there.
I saw the block list inside the extension, but I think an allow list makes more sense for this use case. That way, .ycombinator.com or .example could work as opt-in for instant replay, and ideally, those domains could be preconfigured at the team level.
Acknowledging Chrome's extension per-site permissions is a valid option, but it's clunky.
+1 vote for a datadog integration, in addition to backend data I would love to see this work well with RUM. For now, I'll settle for jamming a common ID into Jam.Metadata and see how that works out.
I also thought Jam would accept bug reports from end-users and look forward to the development of that feature.
Comments synced to timestamps in the recordings are nice. Have you considered a scribble/annotation like the still screenshots, but for videos? The annotations could be anchored to the comment timestamp, and they would help capture a UX micro-interactions that may not be obvious in a still or video.
I think the reason for having the permissions for all sites is for when you want to use the instant replay feature on the off chance and you realise that there were no permissions enabled for the specific domain.
I'd be pretty annoyed if the bug is not reproducible and I lose that chance of generating a bug report.
I'd be pretty annoyed if the bug is not reproducible and I lose that chance of generating a bug report.
That’s great feedback! The way we currently solve that is by setting a memory limit for Instant Replay and then automatically disabling that feature when the limit gets tripped.
Yeah +1, the reason why we built a blocklist vs an allow list is because Chrome settings already allows you to specify an allow list for extensions so we were just trying to round out what settings you couldn’t set already in the browser.
Also I love the idea of annotating a video, sharing that with the team! Thank you!
Yeah +1, the reason why we built a blocklist vs an allow list is because Chrome settings already allows you to specify an allow list for extensions so we were just trying to round out what settings you couldn’t set already in the browser.
Also I love the idea of annotating a video, sharing that with the team! Thank you!
Okay, so, stupid question; could you replace this with this screen recorder[1] and browsers' built-in web dev tools[2] ? The screen recorder lets you record and download a session (nothing is uploaded), and the dev tools lets you capture any errors the browser sees, the network connections & errors, the source, browser data/steps, yadda yadda.
The built-in web dev tools have a Recorder function to record what the browser is doing while also recording video[3]. You can export the recording in a number of formats. It can replay it, let you edit steps, even simulate a slow network. Seems like a product person could follow a simple guide to record and export a session, and send it to a dev?
[1] https://toolbox.googleapps.com/apps/screen_recorder/ [2] https://developer.chrome.com/docs/devtools/ [3] https://developer.chrome.com/docs/devtools/recorder
The built-in web dev tools have a Recorder function to record what the browser is doing while also recording video[3]. You can export the recording in a number of formats. It can replay it, let you edit steps, even simulate a slow network. Seems like a product person could follow a simple guide to record and export a session, and send it to a dev?
[1] https://toolbox.googleapps.com/apps/screen_recorder/ [2] https://developer.chrome.com/docs/devtools/ [3] https://developer.chrome.com/docs/devtools/recorder
When we were PMs at Cloudflare, we were always exporting browser sessions with HAR. Definitely there are ways to do anything, but we wanted to make it as simple as possible both for the PM and for the dev.
Kind of funny, I was just looking at adding similar functionality to an internal Chrome plugin I built because we struggle to get enough useful info in bug reports (being able to look at the HAR, in particular, is useful, but difficult to get users to do correctly).
Two questions -
1) Any way to customize which headers/cookies get scrubbed?
2) Is there a way to get something like the lower-level export you can get by going to chrome://net-export/?
Two questions -
1) Any way to customize which headers/cookies get scrubbed?
2) Is there a way to get something like the lower-level export you can get by going to chrome://net-export/?
Ha, that’s cool!
We don’t have a way to customize that yet but we absolutely need to build that
And yes! Network logs get captured and added to the bug report automatically and we have copy as curl too so you can retry the request locally
We don’t have a way to customize that yet but we absolutely need to build that
And yes! Network logs get captured and added to the bug report automatically and we have copy as curl too so you can retry the request locally
This would have been so useful this past week while we debugged something that ended up being a weird combo of Comcast/Cloudflare/http3 - only some people could reliably reproduce it and it was a lot to coach them through all the steps.
Being able to redact a few values would be really important for us (I just wrote Python scripts to clean the har files up), but I’m going to play around with it this weekend.
Being able to redact a few values would be really important for us (I just wrote Python scripts to clean the har files up), but I’m going to play around with it this weekend.
Some thoughts:
- Make the scrubbed headers configurable (if it isn't already). For example, our token header is called `X-Session-Token` and is passed on every request. Would your current regex scrub this?
- Maybe clarify that the seat (pricing) is for recorders, not for people viewing them (which I think is a reasonable choice).
- Would be nice to configure auto-deletion of Jams after X days. We'd probably go with 180 days.
- Would be neat if the Sentry integration had configurable fields (at the team level set which ones are visible, and set fixed values for some of them). For example, I don't want anyone to set the project (that's the triage step in Linear), and I want only some teams to be selectable, I'd like to skip the 'effort' altogether, etc.
- Make it possible to configure the text body of the Linear issue, with placeholders for content. For example, we'd like to skip the full-screen (non-cropped), maybe show window size or add other metadata that is often relevant to us.
One question:
- For integration with Linear, you are asking for write access to the workspace. Maybe explain why that's needed, and what it means? Same for read (though this seems more reasonable, an explanation would still be useful)
- Make the scrubbed headers configurable (if it isn't already). For example, our token header is called `X-Session-Token` and is passed on every request. Would your current regex scrub this?
- Maybe clarify that the seat (pricing) is for recorders, not for people viewing them (which I think is a reasonable choice).
- Would be nice to configure auto-deletion of Jams after X days. We'd probably go with 180 days.
- Would be neat if the Sentry integration had configurable fields (at the team level set which ones are visible, and set fixed values for some of them). For example, I don't want anyone to set the project (that's the triage step in Linear), and I want only some teams to be selectable, I'd like to skip the 'effort' altogether, etc.
- Make it possible to configure the text body of the Linear issue, with placeholders for content. For example, we'd like to skip the full-screen (non-cropped), maybe show window size or add other metadata that is often relevant to us.
One question:
- For integration with Linear, you are asking for write access to the workspace. Maybe explain why that's needed, and what it means? Same for read (though this seems more reasonable, an explanation would still be useful)
[I work at Jam]
- Yep, your header would be scrubbed by our default definition. And also: yes definitely, configurable scrubbing is on our radar/an inevitability. Sensible defaults has been our goal, but we're definitely aware that any given keyword may be sensitive to one company but not be to another! (e.g, an address in the context of a healthcare org's patients may be sensitive, but likely wouldn't be considered sensitive for an MLS search product)
- Re: Sentry — Makes sense! There's likely a lot of team-level configuration we can add for integrations over time
- Re: Linear — that's a good question. We used to have much deeper integration with some third parties, so I think we may be able to tighten up some of those scopes. I created a ticket for us to follow up on this, thank you!
- Yep, your header would be scrubbed by our default definition. And also: yes definitely, configurable scrubbing is on our radar/an inevitability. Sensible defaults has been our goal, but we're definitely aware that any given keyword may be sensitive to one company but not be to another! (e.g, an address in the context of a healthcare org's patients may be sensitive, but likely wouldn't be considered sensitive for an MLS search product)
- Re: Sentry — Makes sense! There's likely a lot of team-level configuration we can add for integrations over time
- Re: Linear — that's a good question. We used to have much deeper integration with some third parties, so I think we may be able to tighten up some of those scopes. I created a ticket for us to follow up on this, thank you!
Quick follow up on the integration with Linear: just confirmed that we do not need write scopes on the workspace. The fix will be in production by next week :)
Great, thanks!
I made a mistake in my comments above:
I meant to write "Would be neat if the *Linear* integration had configurable fields (at the team level set which ones are visible, and set fixed values for some of them). For example, I don't want anyone to set the project (that's the triage step in Linear), and I want only some teams to be selectable, I'd like to skip the 'effort' altogether, etc."
I made a mistake in my comments above:
I meant to write "Would be neat if the *Linear* integration had configurable fields (at the team level set which ones are visible, and set fixed values for some of them). For example, I don't want anyone to set the project (that's the triage step in Linear), and I want only some teams to be selectable, I'd like to skip the 'effort' altogether, etc."
Looks awesome, thanks for sharing. I definitely am also fighting with this. Common complaints "where is the video?" "where is the HAR file" etc. Their repro steps are usually bad.
So automatic repro steps sound great.
Looking at the homepage on that though it seems way too detailed and will fall prey to how I see our support and PM staff reporting bugs via videos they record today already: too many clicks and steps that are not necessary and when I try the exact same thing it works correctly.
The hard part of proper steps to reproduce is to reproduce it with a minimal set of steps that are also actually reproducible "from zero".
(of course there are some bugs that are very specific to some specific customers data you won't be able to repro but they are in the minority at least for us)
How do you solve that part?
So automatic repro steps sound great.
Looking at the homepage on that though it seems way too detailed and will fall prey to how I see our support and PM staff reporting bugs via videos they record today already: too many clicks and steps that are not necessary and when I try the exact same thing it works correctly.
The hard part of proper steps to reproduce is to reproduce it with a minimal set of steps that are also actually reproducible "from zero".
(of course there are some bugs that are very specific to some specific customers data you won't be able to repro but they are in the minority at least for us)
How do you solve that part?
It’s a super interesting problem
I wonder if soon LLMs are going to be able to help us get automatic repro steps to be exactly the right level of detail for an engineer.
I wonder if soon LLMs are going to be able to help us get automatic repro steps to be exactly the right level of detail for an engineer.
We have been using Jam on our team for a long time (~2 years) and it is awesome! Everyone on our team is posting jam videos to report bugs, explain and walkthrough issues, add a demo on every PR with a demo of what frontend changes are included in the ticket so that QA can get a jump start on understanding the scope of what to test.
I normally just record the jam and get a link and paste it wherever, but I love the ability to have Jam create jira tickets for me. And THANK YOU for making it easy to choose the sprint! the Slack Atlassian plugin makes it impossible to find the sprint and shows all the closed sprints that cannot be used for new tickets.
Really an awesome tool. I have been using it to report bugs for any random open source project I am working on.
I normally just record the jam and get a link and paste it wherever, but I love the ability to have Jam create jira tickets for me. And THANK YOU for making it easy to choose the sprint! the Slack Atlassian plugin makes it impossible to find the sprint and shows all the closed sprints that cannot be used for new tickets.
Really an awesome tool. I have been using it to report bugs for any random open source project I am working on.
You just made my day :) that is so amazing to hear, thank you so much. Feel free to reach out anytime for feature requests, suggestions, product gripes, anything! I’m [email protected]
Does anyone have any stats on how successful these small niche tool shops are from the business perspective? On the one hand $8/mo is pretty negligible. But on the other people will go to great lengths to not have “yet another subscription”. If we run some math a shop of 10 people in the US is at least $2.5M in just comp outlay per year, all in (meaning the entire comp package, not just net pay). At 96 bucks per year that’s about 26K users (assuming zero marketing expenses and zero cost of accepting payment) which idk if that’s realistic or not for a nice to have tool like this. What’s the business plan here? Is there a business plan?
You don’t need 10 people to run this business in 2024. They could definitely do it with half that. They could probably do it with 2 people.
If they do staff up (eg if they have raised capital) they will eventually go up market or into adjacent markets.
That said, there are millions of software developers in the world. They can probably find 26k customers.
If they do staff up (eg if they have raised capital) they will eventually go up market or into adjacent markets.
That said, there are millions of software developers in the world. They can probably find 26k customers.
I used 10 as a nice round number. You can scale it up or down with linear effects on the rest of this napkin math. Their careers page by the way has 8 open positions as of the time of this writing. Don’t get me wrong, I’m not saying this isn’t viable, I’d just like to understand how.
The economics are very different though without the overhead of a large team.
If they have 8 openings they have raised a round and probably already have slides in the deck about their plans to go upmarket and sell giant licenses to large tech companies. They want to close deals that are 25-100k/year that cover big chunks of the org.
If they have 8 openings they have raised a round and probably already have slides in the deck about their plans to go upmarket and sell giant licenses to large tech companies. They want to close deals that are 25-100k/year that cover big chunks of the org.
I didn't dig too deeply so maybe I missed it but your site doesn't mention how this works from a technical standpoint, i.e. do both reporters and devs need to have this extension installed, or just the reporters? If just the reporters, in what format are the bug reports captured? I.e. if it's a video plus metadata, does it save a .mp4 (or whatever) video file plus a .json file with the metadata?
Knowing more up front about how the whole thing works would make me more inclined to try it, especially since I'm wary of tools that take liberties with what they capture and store.
Knowing more up front about how the whole thing works would make me more inclined to try it, especially since I'm wary of tools that take liberties with what they capture and store.
Just the reporter. Metadata + screenshot / video / instant replay. You can download the videos.
I've definitely felt this problem! Web app development can feel like 'playing detective' and chasing down lines more than problem solving. I'd download right now but will it help debug chrome extensions?
Ooh we’ve considered building a Jam for debugging extensions (honestly it would really help us to have that!). We should!
Thank you all so much for all your feedback and support. The team and I are blown away by your ideas and thoughts — it means a lot and it’s been such a magic of the internet moment to get to talk to 150 of you about this project we’ve spent four years on so far. You’ve helped us decide on some next features and I hope when you see them ship they are what you hoped to see when you suggested them here in this thread. Thank you all, HN you are an awesome place. Have a great weekend, y’all!
A little under 10 years ago I used a product that was designed for improving the website by providing heat maps, but also let you drill down to individual sessions. You could see everything, from console to UI to mouse movements. It was actually pretty neat and incredibly useful for debugging.
It was so neat and useful that as an engineering team we had to hide it from the rest of the company because we were worried it would be used to “spy” on employees. (Id like to note that it was only ever installed on internal tooling that was custom built)
How has jam addressed this concern?
Also, is there self hosting?
It was so neat and useful that as an engineering team we had to hide it from the rest of the company because we were worried it would be used to “spy” on employees. (Id like to note that it was only ever installed on internal tooling that was custom built)
How has jam addressed this concern?
Also, is there self hosting?
That sounds super useful!
Rather than passively record sessions like the tool you’re describing, Jam is an active model. It lets you actively choose when to record the screen. That way we’re able to avoid any creepiness!
We actually get a lot of requests for self hosting and it’s something I think would be great to add in the future.
Rather than passively record sessions like the tool you’re describing, Jam is an active model. It lets you actively choose when to record the screen. That way we’re able to avoid any creepiness!
We actually get a lot of requests for self hosting and it’s something I think would be great to add in the future.
Very cool; I use Yandex Metrica for this on public sites
We've started using this. It's fantastic! Great work. Thank you :)
Ah that makes me so happy to hear!! Thank you. If ever you have feature requests or anything, I’d love to hear: [email protected]
Pretty soon after the initial launch of Jam.dev I tried as an alternative to Bugherd. At the time it was only screenshots and annotations and we were missing the browser information provided by the currently used tool.
It seems it's time to try it again, after many evolutions. As we mostly did frontend development and wanted feedback from clients, the killer feature for me was the selection and capture of a specific HTML element.
Thanks for trying us out back then! It’s been quite a journey since the initial launch - we ended up building & rebuilding 7 times since then. What’s now live at Jam is our 8th attempt at solving the slow back & forths about bugs, I hope you like where the product has iterated to!
This is an useful tool. I wish there was something similar for desktop applications.
The nice thing about implementing this for the web is that the API you have to record data from (DOM events) is the same no matter what UI toolkit you use on top of it. But on desktop, the ecosystem is more fragmented and would require more ports and quirks to implement a widely compatible bug recorder.
I'm not a fan of webdev, but this is an advantage it has over desktop development.
The nice thing about implementing this for the web is that the API you have to record data from (DOM events) is the same no matter what UI toolkit you use on top of it. But on desktop, the ecosystem is more fragmented and would require more ports and quirks to implement a widely compatible bug recorder.
I'm not a fan of webdev, but this is an advantage it has over desktop development.
Totally, it’s going to be a bit of a beast to tackle but really excited to do so. Would love any thoughts on how we should think about doing this for desktop! I’m [email protected] if that’s easiest.
Nice work!
Suggestions
1)Jam requires being on a website page to load, which might not always align with how users interact with browser extensions, often using them independently of a webpage
2) Wouild be nice to have an option to record two windows
3) Visibility of the extension popup in recordings when sharing a browser window - I can see extension popup open on the recording only when I share the entire screen
Thank you! Haven't explored all functionality yet but already love Jam <3
1)Jam requires being on a website page to load, which might not always align with how users interact with browser extensions, often using them independently of a webpage
2) Wouild be nice to have an option to record two windows
3) Visibility of the extension popup in recordings when sharing a browser window - I can see extension popup open on the recording only when I share the entire screen
Thank you! Haven't explored all functionality yet but already love Jam <3
That is amazing to hear!! Thanks for giving us a try.
1 - that’s so true, hadn’t considered that. Thank you!
2 - yes! Right now we just have window vs desktop but definitely there’s more to be done there
3 - +1
Great feedback thank you!
1 - that’s so true, hadn’t considered that. Thank you!
2 - yes! Right now we just have window vs desktop but definitely there’s more to be done there
3 - +1
Great feedback thank you!
Not sure being "ex-Cloudflare" gives you the positive credentials you think it does.
Pretty much all "Cloudflare" experience most people have will be something negative, like getting blocked from some website, just seeing the huge clouflare logo instead. Even as a programmer, I pretty much just hate Cloudflare, despite knowing it's more than this annoying screen or stupid captcha between me and some website.
Pretty much all "Cloudflare" experience most people have will be something negative, like getting blocked from some website, just seeing the huge clouflare logo instead. Even as a programmer, I pretty much just hate Cloudflare, despite knowing it's more than this annoying screen or stupid captcha between me and some website.
Haven't heard of this before, seems very useful!
God I wish there was something like this for mobile apps, though. Or a website running on the user's mobile device browser. I know Firefox Android does support extensions, but most people on Android use Chrome. And I think on iOS the browser extension situation was miserable the last time I read about it. Either way, an app would probably be the best way to do it.
God I wish there was something like this for mobile apps, though. Or a website running on the user's mobile device browser. I know Firefox Android does support extensions, but most people on Android use Chrome. And I think on iOS the browser extension situation was miserable the last time I read about it. Either way, an app would probably be the best way to do it.
Yeah! Looks like iOS safari might be the only mobile browser which supports extensions at the moment which is too bad, because the bug reporting problem is very real for mobile
Firefox on Android too, though probably ~nobody uses that.
I do!
Me too, but I'm comfortable being in the ~nobody club. Basically everyone uses the browser bundled with their phone, right? Whether that's Safari or Chrome or whatever Samsung ships these days.
Also check Orion!
Are there extensions planned for other browsers? It seems right now when you click on "get jam" button, it takes me to the chrome web store.
I wanted to know the same and had to dig into the Docs section on the website to find that it currently supports all Chromium based browsers. Support for other browsers is said to be coming in the future.
Yeah! Right now Jam works on Chrome, Brave, Edge, Arc and Opera. We need to build a Safari and Firefox version. It’s a must do!
Looks like 'large free plan' includes 25 jams. I was able to make only 10 or so jams (I could have deleted some jams but no more than 2 or 3) and now I have to 'Upgrade'.
Disregard the last part about 'I was able to make only 10 or so jams'. I still can create jams, but I haven't hit 25 jams limit yet.
I think this is really awesome. Our company has a monolithic giant that is full of tech debt and high support cost from our on premise web application. Half the battle is asking the clients to send screenshots or properly explain the issue. For us would be an easy sell if we could integrate natively with the apps front end tech stack.
Gleap does this: https://www.gleap.io/in-app-bug-reporting
Ooh that’s great feedback, thank you!
I would of preferred this as a stand alone electron app. I don't feel comfortable with giving a random extension the power to control my entire browser, particularly in a work environment.
That said, this looks outstanding, it could really be a great option for QA teams.
That said, this looks outstanding, it could really be a great option for QA teams.
This is very cool! One of the hardest things in tech is to teach non tech people to write decent bugs.
Our team wouldn’t be able to use this because HAR records at L7 only, after browser content-decoding. A lot of the problems we find end up with symptoms revealed by the encoder or decoder.
Not to steal your thunder but we're building the same tool [1] but for the WHOLE desktop experience, not just the browser - if anyone has any feedback I'd love to talk to you!
[1] https://www.dashcam.io
[1] https://www.dashcam.io
Looks really good. And it's a better fit for my work on a CLI app that makes no use of a browser.
Looks great!
Heads up, for the `Backend Tracing` screenshot there's a typo, it reads "enviroment" with the missing 'n' and on the AI debugger page on narrower screens the bubble for the "Learn more about JamGPT" text doesn't fit the text.
Heads up, for the `Backend Tracing` screenshot there's a typo, it reads "enviroment" with the missing 'n' and on the AI debugger page on narrower screens the bubble for the "Learn more about JamGPT" text doesn't fit the text.
Thank you!!
Looks very useful for developers but I am not a fan of being on a website that has a keylogger installed onto it. I know this is not the first tool to do this, but the thought of every single thing I do getting stored by some third party tool is a bit scary.
[disclosure: I work at Jam]
I generally agree with you. I think there's a few important things to note:
- Since Jam is a browser extension, its functionality only applies to the user that installed it (i.e., only you, not everyone that visits website X) - All captured data stays locally in your browser until _you choose_ to submit a bug and its details* - You can choose which sites the extension is enabled on if you want to further limit the scope of functionality - We have some user preferences to enable/disable certain functionality of Jam already, and I'm confident we'll add more over time!
* to be fully transparent: we _do_ collect application telemetry so we can identify bugs and performance issues, but we take great care in reporting information that is centered around what our application is doing, not what it is capturing.
I generally agree with you. I think there's a few important things to note:
- Since Jam is a browser extension, its functionality only applies to the user that installed it (i.e., only you, not everyone that visits website X) - All captured data stays locally in your browser until _you choose_ to submit a bug and its details* - You can choose which sites the extension is enabled on if you want to further limit the scope of functionality - We have some user preferences to enable/disable certain functionality of Jam already, and I'm confident we'll add more over time!
* to be fully transparent: we _do_ collect application telemetry so we can identify bugs and performance issues, but we take great care in reporting information that is centered around what our application is doing, not what it is capturing.
Every single website is a keylogger. Act accordingly.
See: PostHog (YC W20)
https://news.ycombinator.com/item?id=22376732
https://news.ycombinator.com/item?id=22376732
Too cheap.
It seems extremely inexpensive.
Even though it's not a direct comparison, look at https://www.hotjar.com/pricing/ (and switch to the "pay by month" pricing view)
It seems extremely inexpensive.
Even though it's not a direct comparison, look at https://www.hotjar.com/pricing/ (and switch to the "pay by month" pricing view)
"Suspiciously cheap" is on-brand for an ex-Cloudflare team
I wouldn't call charging $5/user "cheap" when a user might cost a few cents. Pure software services are supposed to have insane COGS. The free tier may eventually get reduced, but with something like this you have basically no lock-in, so I wouldn't consider that a meaningful risk.
I would have easily paid for any of their best in class DNS, DDoS protection or CDN, but I get all of those free unmetered. Generally when this happens, I get suspicious that they are just trying to kill the competition and then increase price, but cloudflare has been free for almost like forever.
It's no secret that those products are free* with a big asterisk, if you hit some unspecified combination of total bandwidth usage, attracting DDoSes, serving the wrong types of files or moving too much data in regions where bandwidth is expensive then you get an email from sales asking you to pay up or leave. Even if you're on a paid plan, beyond a certain (also unspecified) amount of usage they will ask you to pay more, until you end up on an Enterprise plan where you pay-per-GB just like every other CDN.
They are currently quite generous with how much you can use for free or cheap, but the limits being so vague means they are subject to change without any transparency, potentially pulling the rug on you at any time. That's what I mean by suspiciously cheap.
They are currently quite generous with how much you can use for free or cheap, but the limits being so vague means they are subject to change without any transparency, potentially pulling the rug on you at any time. That's what I mean by suspiciously cheap.
Do you have any source? I was initially suspicious of the same but found few content in reddit/other forums where multiple users said they have free plan and get millions of requests per day[1]. And I couldn't find a consistent reason for all the sites that cloudflare banned.
[1]: https://www.reddit.com/r/programming/comments/lfa1il/why_you...
[1]: https://www.reddit.com/r/programming/comments/lfa1il/why_you...
Cloudflare does not have any bandwidth limits or request limits in any way. They generally do monitor high usage users on lower plans to try and upsell them to enterprise but you dont ever have to actually upgrade.
The reddit post you linked seems to not really have any content anymore, but I would be willing to bet they broke TOS given you are only really supposed to serve html content over CDN when on lower level plans when you are not using the developer platform to host the content such as videos/images/etc.
Fwiw though, if you are a business you probably should at the very least upgrade to business for the SLA and to create support tickets if needed.
edit: figured out why the article doesnt exist the OP removed it because it was an issue on his end not Cloudflares. (Using bot fight mode on a route supposed to be used by bots) https://news.ycombinator.com/item?id=26072153
The reddit post you linked seems to not really have any content anymore, but I would be willing to bet they broke TOS given you are only really supposed to serve html content over CDN when on lower level plans when you are not using the developer platform to host the content such as videos/images/etc.
Fwiw though, if you are a business you probably should at the very least upgrade to business for the SLA and to create support tickets if needed.
edit: figured out why the article doesnt exist the OP removed it because it was an issue on his end not Cloudflares. (Using bot fight mode on a route supposed to be used by bots) https://news.ycombinator.com/item?id=26072153
Looks like the Jam team have some great investors who will steer them correctly but the founders need to consider whether they can raise the amounts needed the same way Matthew and Michelle (founders of CloudFlare) could back in the day - which enabled the generous CF freemium model and turned the company into the $25bn company it is today.
From a funding perspective things are very different than when CF started.
From a funding perspective things are very different than when CF started.
Cant really compare these at all. Hotjar is for tracking heatmaps and recordings from your regular site visitors.
Jam is for your employees to download an extension and manually submit the recordings when they have issues and is a pay per employee based model.
Jam will generally have very low volume compared to Hotjar which is where the price difference really is
Jam is for your employees to download an extension and manually submit the recordings when they have issues and is a pay per employee based model.
Jam will generally have very low volume compared to Hotjar which is where the price difference really is
Really cool product.
One of those ideas/things that seems to just be "obvious" after the fact. Especially in the realm of bug reports which are very tedious to submit.
Kinda inspiring me to try and look around me for similar problems to solve.
One of those ideas/things that seems to just be "obvious" after the fact. Especially in the realm of bug reports which are very tedious to submit.
Kinda inspiring me to try and look around me for similar problems to solve.
That’s so nice to hear, excited to see which problem you end up on!
I wish there were a way to trigger the bug reporter right on their landing page, so I can try it out from a user's point of view.
Edit: never mind - I see this is a browser extension, so kind of a non-starter.
Edit: never mind - I see this is a browser extension, so kind of a non-starter.
Nice looking landing page. Small bug, when I scroll down the page and then click "pricing" it doesn't take me to the right spot on the page until I click again. On Firefox 125.0.3
Can you use https://jam.dev/ to file the bug report?
Joking aside, this looks really cool!
Joking aside, this looks really cool!
Ahahaha thank you!!
They dont even support Firefox with thier browser extension product. Looks like this team give Firefox very little love :(
On it! Thanks for letting me know!
The thing I love the most about Sentry/Bugsnag/Honeycomb/etc is that it is essentially automated observability. That is, I don't need to do a huge amount of integration to have, basically, a prioritized list of bugs along with severity and overall application health.
I like the idea of the browser extension being able to offer these kinds of tools where you wouldn't need to install a heavy Javascript snippet -- but I do think that taking the manual steps out of debugging wherever you can is the most efficient. With Bugsnag et al, I don't need to wait for a user to contact me. I shouldn't have to wait for someone to submit a Jam report in order to see how healthy my app is.
I like the idea of the browser extension being able to offer these kinds of tools where you wouldn't need to install a heavy Javascript snippet -- but I do think that taking the manual steps out of debugging wherever you can is the most efficient. With Bugsnag et al, I don't need to wait for a user to contact me. I shouldn't have to wait for someone to submit a Jam report in order to see how healthy my app is.
I think they serve different purposes.
Sentry/Bugsnag etc track code errors and exception. But sometimes for an user an error is not a code exception, but the software having the wrong behaviour.
Some examples:
> "The button brings me to the wrong page"
> "I filled out the whole form but the submit button is not enabled"
> "The video should autoplay but is stuck loading"
Those things do not show up in Sentry logs.
Sentry/Bugsnag etc track code errors and exception. But sometimes for an user an error is not a code exception, but the software having the wrong behaviour.
Some examples:
> "The button brings me to the wrong page"
> "I filled out the whole form but the submit button is not enabled"
> "The video should autoplay but is stuck loading"
Those things do not show up in Sentry logs.
Sentry has session replay that should catch all of these things - it doesn't look any higher friction than this tool.
Only if an exception is raised. The alternative is to record every user session, resulting in a privacy mess.
This tool allows the reporter to select when data should be collected
This tool allows the reporter to select when data should be collected
I see these tools as complimentary. Sometimes Sentry &al don't capture a user session (blocking, didn't consent &c) and this tool acts as a nice fallback you can instruct the user to use rather than having to explain how to open dev tools and screenshot the console.
Looks similar to replay.io
What I don't like about replay.io is that it requires you to use their custom browser.
Hi, I work at Replay.io. There's a very good reason for that "custom browser" requirement.
Session replay tools like LogRocket or Jam do capture a lot of information, but they can only capture what's _in_ the page, and are thus limited by the JS execution environment and permissions. This is still very useful for seeing what the user did in the page, and you do get a good amount of detail (video, DOM, network).
Replay.io works by capturing the browser's calls into the operating system. (This is really complicated! Our fork of Chromium has thousands of lines of custom C++ and JS modifications in order to capture the runtime information and make it queryable.) That enables actually _debugging_ any line of code that ran at any time. That's something that session replay tools _can't_ do.
So, yes, both Replay.io and session replay tools let you _see_ what happened, but only Replay.io lets you _debug_ the code _as it ran originally_. And that's only possible because we do capture the _entire_ browser's execution.
We've got some sections in our docs that dive into this in more detail:
- https://docs.replay.io/time-travel-intro/what-is-time-travel...
- https://blog.replay.io/how-replay-works
- https://docs.replay.io/comparison/session-replay
Not only does Replay.io let you _debug_ recordings of bugs, we've got a Test Suites dashboard that lets you record Playwright or Cypress E2E tests _as they ran in CI_. This is possible because we can run your E2E tests with our own browser, and thus record them as they're running.
Finally, a sneak peak: we're currently prototyping some new advanced functionality that would actually _diff_ passing and failing E2E tests to figure out where a failing test went wrong, surface that info to developers, and help them identify common failure reasons in their tests ("27% of your failures in the last month were due to Apollo Client failing to connect"). Still very early, but we've got the core functionality working! Again, this is only possible because we've recorded the _entire_ browser's execution, and can then replay that browser at will and query for every bit of JS execution that happened.
Session replay tools like LogRocket or Jam do capture a lot of information, but they can only capture what's _in_ the page, and are thus limited by the JS execution environment and permissions. This is still very useful for seeing what the user did in the page, and you do get a good amount of detail (video, DOM, network).
Replay.io works by capturing the browser's calls into the operating system. (This is really complicated! Our fork of Chromium has thousands of lines of custom C++ and JS modifications in order to capture the runtime information and make it queryable.) That enables actually _debugging_ any line of code that ran at any time. That's something that session replay tools _can't_ do.
So, yes, both Replay.io and session replay tools let you _see_ what happened, but only Replay.io lets you _debug_ the code _as it ran originally_. And that's only possible because we do capture the _entire_ browser's execution.
We've got some sections in our docs that dive into this in more detail:
- https://docs.replay.io/time-travel-intro/what-is-time-travel...
- https://blog.replay.io/how-replay-works
- https://docs.replay.io/comparison/session-replay
Not only does Replay.io let you _debug_ recordings of bugs, we've got a Test Suites dashboard that lets you record Playwright or Cypress E2E tests _as they ran in CI_. This is possible because we can run your E2E tests with our own browser, and thus record them as they're running.
Finally, a sneak peak: we're currently prototyping some new advanced functionality that would actually _diff_ passing and failing E2E tests to figure out where a failing test went wrong, surface that info to developers, and help them identify common failure reasons in their tests ("27% of your failures in the last month were due to Apollo Client failing to connect"). Still very early, but we've got the core functionality working! Again, this is only possible because we've recorded the _entire_ browser's execution, and can then replay that browser at will and query for every bit of JS execution that happened.
IDK.
Sanitizing chrome for testing makes a lot of sense as different versions of chrome have been proven to be unreliable.
Playwright uses a sanitized chrome version.
And Cypress does not, and allows users to use their own browsers which may be a reason for some not insignificant portion of flake. They definitely had multiple instances where a particular chrome version was unstable leading to lots of customer complaints regarding their reliability.
Sanitizing chrome for testing makes a lot of sense as different versions of chrome have been proven to be unreliable.
Playwright uses a sanitized chrome version.
And Cypress does not, and allows users to use their own browsers which may be a reason for some not insignificant portion of flake. They definitely had multiple instances where a particular chrome version was unstable leading to lots of customer complaints regarding their reliability.
honestly that ends up being a feature rather than a bug for me, given how many chrome windows and chrome profiles going on, having it be a separate so entirely is a good thing in my book. I can understand others have a different opinion though. Given all the attention paid to the developer experience, what's weird is CORS not being called out in their browser.
Would love it if this supported more than web. Android, ios, etc.
nice work, love the landing page design, messaging/copy could be improved slightly. I was confused on how it was supposed to help me without going deeper if that makes sense.
Thank you! That’s great feedback, a few other people mentioned the copy could be clearer in the HN thread. That’s so important for us to know, appreciate you saying so!
I would love it if you could bundle this into electron, there’s so many random electron apps for which the bug reporting workflow is still stuck in the 90s as you say.
That will be really awesome!
I think SAML should be available for business tier as well.
I'll draft a PR to put them on the SSO wall of shame at https://sso.tax/ when I'm at a laptop
BTW: https://ssotax.org is more up2date
+1, great feedback
Is there any reason 'enterprise' features can't be purchased a-la-carte if your org is <X size? Or for a team of X people in a bigger org? Like, if our company has 10,000 people, but only 15 people are ever going to use your tool, we cannot justify the Enterprise pricing... I run into this all the time :(
Do you think this would work as a bug reporting solution for a desktop app using electron?
I make beekeeper Studio and struggle with bug reports being very vague
I make beekeeper Studio and struggle with bug reports being very vague
I'd love to chat to you - what's a good email to get in touch?
Hey! I'm Matthew (at) beekeeperstudio.io
I thought I should know that your main page is lagging super badly on machines without GPU acceleration
This looks really interesting, but I want to walk you through the journey I just had on your pricing page.
1. This looks really cool and it has a free tier. 2. Okay you have to pay for bug trackers...oh cool they support Linear and it's only $8. Maybe I'll just put that on my creditcard and get the founders to pay for it once it's proven itself. 3.Oh wait that's for two users and I have 2 founders (non tech), 3 techs and then 1.5 designers. Oh the business tier is $50, well I guess I'll maybe discuss it with the founders.
My contact details are on my profile if you want further feedback, I have to run to a meeting.
1. This looks really cool and it has a free tier. 2. Okay you have to pay for bug trackers...oh cool they support Linear and it's only $8. Maybe I'll just put that on my creditcard and get the founders to pay for it once it's proven itself. 3.Oh wait that's for two users and I have 2 founders (non tech), 3 techs and then 1.5 designers. Oh the business tier is $50, well I guess I'll maybe discuss it with the founders.
My contact details are on my profile if you want further feedback, I have to run to a meeting.
Appreciate your feedback!
Feel free to reach out and we can give you some free credits to your account: [email protected]
We really just care that we can help you streamline bug reporting, we don’t want the pricing to get in the way.
Feel free to reach out and we can give you some free credits to your account: [email protected]
We really just care that we can help you streamline bug reporting, we don’t want the pricing to get in the way.
On the pricing aspect do viewers of Jam reports get charged as a seat or just the staff that are creating the Jam reports? Eg. if a Jam report is attached to a JIRA ticket does everyone who might ever need to view that report need to have a Jam license/login to view that information?
Turn it into a product for corporate surveillance and you’ll have a much bigger market.
Might want to fix the typo in the feature list "Om-premise data storage" :)
This looks awesome. Any tips on getting my support people to actually use it?
Thank you! Haha hopefully they love it because it makes them faster at reporting bugs too. Jam creates the ticket for them and auto-fills details like browser/OS and repro steps so they can spend less time filing bugs.
So it uploads my bug videos to a central server? Interesting...
This looks incredible. Congrats on launching this.
Thank you so much!! So kind of you
Awesome! Will definitely give it a try!
Is it something similar to Userback?
Can this be added to electron apps?
I dont work at jam but I built one in electron to debug electron apps...desktop apps...all apps - wanna chat?
do you have a hipaa compliant version?
Great work!
Why isn't this opensource?
super duper!
Sorry, but the need to create an account was an instant uninstall.
You may want to use a different example than ‘cheese pizza’ on the homepage…
https://en.wiktionary.org/wiki/cheese_pizza
https://en.wiktionary.org/wiki/cheese_pizza
I wouldn't use "cloudflare" as a selling point. People that have used cloudflare know how good the engineering work they do actually is.
Afaik, only Cloudflare's "checking if the site connection is secure" pages are rubbish. And while those are really rubbish (as a web user), the stuff they talk about on their devblogs seems quite solid. I don't think your generalisation is valid.
> It’s actually really hard as a non-engineer to file useful bug tickets for engineers... So the engineer would be frustrated, I would be frustrated
While I have been in this scenario before, saying something along the lines of, "If I don't get 100% bug reports, I can't do 100% bug fixes," 9 years of experience and maturity later: no, I wouldn't use this. It wouldn't engender me more respect, power or efficacy in the organization if I "just" "educated" PMs on how to file bugs, or if I "just" used some tool for them.
I should have just not asked non-engineers to ticket bugs or do QA. If that is happening, you are already failing in terms of leadership and organization. Most products fail, so that's not saying much, and they rarely fail due to bugs, which is also not saying much. That said, the best technical solution is clearly comprehensive tracing, and the best cultural solution is that engineers responsible for an end user experience must manually QA all paths.
While I have been in this scenario before, saying something along the lines of, "If I don't get 100% bug reports, I can't do 100% bug fixes," 9 years of experience and maturity later: no, I wouldn't use this. It wouldn't engender me more respect, power or efficacy in the organization if I "just" "educated" PMs on how to file bugs, or if I "just" used some tool for them.
I should have just not asked non-engineers to ticket bugs or do QA. If that is happening, you are already failing in terms of leadership and organization. Most products fail, so that's not saying much, and they rarely fail due to bugs, which is also not saying much. That said, the best technical solution is clearly comprehensive tracing, and the best cultural solution is that engineers responsible for an end user experience must manually QA all paths.
That's all well and good, but even a halfway engaged PM is going to play with the product while it's in development, and they will tell you about what they discover along the way. It may not strictly be their job but they're going to do it. If a tool exists to help them capture more information that makes their inevitable reports more useful, is that a bad thing?
There is a nuance here: those reports from management should go to QA, not to developers. If QA can't transform manager report into a proper bug report, then it's not worth anything. Also, QA will have time to verify the fix, unlike managers.
That assumes a company that has dedicated QA staff. Most these days don't, and the above comment discusses engineers doing their own QA.
We’d call these non reproducible non errors (200 for GraphQl) as “usefully wrong.” You see this in AI a lot where they spent millions in market research or ask MBA types how to recommend a product and it turns out that someone buying a new laptop tends to also want to buy new shoes. You’d get people like executives not happy they looked bad for spending money on one thing only to find out they were way off. Good news is more revenue makes people look good, so that’s not a hard problem. What’s hard is if a contact us form stops working (bad example), people stop using it but still use the app the same way and spend as much is the form and the people behind it necessary or are people brand loyal and willing to put up just with a minor bug? Similarly if we get something not working and can’t reproduce it did a network card have a low level error that propagated in such a way even our monitoring couldn’t pick it up?
I thought this was a new error in complex systems we have now with hundreds of clusters creating basically non-deterministic problems. But fine I remembered before kernels became better at talking to things like drivers and external hardware we’d see weird bugs outside our boundaries that were really hard to track down and often never manifested themselves in the same way. This is when you’d go to the weird guy no one talked to and in a week he’d have some piece of odd C code with a hex value doing logic no one understood that bypassed whatever error we were having.
It is too bad those guys that I’m pretty sure didn’t do much largely fell victim to the MBA thinking of the 90s. Now we usually will have one team go well we are calling the code right and the other saying they are sending it right and both aren’t wrong except it isn’t working so they are. We’ve reached a point where we have contracts with every vendor because the problem usually is actually like a Cloudflare :) but I’d argue it’d be far easier to just fix or create a work around and file a bug with them then spend more time on daily calls working with someone like you and knowing your progress. So I know what you mean by tools companies use. Unless it has hit industry standard we won’t even evaluate open source as we couldn’t blame someone.
I thought this was a new error in complex systems we have now with hundreds of clusters creating basically non-deterministic problems. But fine I remembered before kernels became better at talking to things like drivers and external hardware we’d see weird bugs outside our boundaries that were really hard to track down and often never manifested themselves in the same way. This is when you’d go to the weird guy no one talked to and in a week he’d have some piece of odd C code with a hex value doing logic no one understood that bypassed whatever error we were having.
It is too bad those guys that I’m pretty sure didn’t do much largely fell victim to the MBA thinking of the 90s. Now we usually will have one team go well we are calling the code right and the other saying they are sending it right and both aren’t wrong except it isn’t working so they are. We’ve reached a point where we have contracts with every vendor because the problem usually is actually like a Cloudflare :) but I’d argue it’d be far easier to just fix or create a work around and file a bug with them then spend more time on daily calls working with someone like you and knowing your progress. So I know what you mean by tools companies use. Unless it has hit industry standard we won’t even evaluate open source as we couldn’t blame someone.
I have now read this comment three times and still don’t know what it is about.
I read it twice and I don't want to read it a third now.
It’s called Jam and it prevents product managers (like I used to be) from being able to create vague and un-reproducible bug tickets (like I used to create).
It’s actually really hard as a non-engineer to file useful bug tickets for engineers. Like, sometimes I thought I included a screenshot, but the important information the engineer needed was what was actually right outside the boundary of the screenshot I took. Or I'd write that something "didn't work" but the engineer wasn't sure if I meant that it returned an error or if it was unresponsive. So the engineer would be frustrated, I would be frustrated, and fixing stuff would slow to a halt while we went back and forth to clarify how to repro the issue over async Jira comments.
It’s actually pretty crazy that while so much has changed in how we develop software (heck, we have types in javascript now*), the way we capture and report bugs is just as manual and lossy as it was in the 1990’s. We can run assembly in the browser but there’s still no tooling to help a non-engineer show a bug to an engineer productively.
So that’s what Jam is. Dev tools + video in a link. It’s like a shareable HAR file synced to a video recording of the session. And besides video, you can use it to share an instant replay of a bug that just happened — basically a 30 second playback of the DOM as a video.
We’ve spent a lot of time adding in a ton of niceties, like Jam writes automatic repro steps for you, and Jam’s dev tools use the same keyboard shortcuts you’re used to in Chrome dev tools, and our team’s personal favorite: Jam parses GraphQL responses and pulls out mutation names and errors (which is important because GraphQL uses one endpoint for all requests and always returns a 200, meaning you usually have to sift through every GraphQL request when debugging to find the one you’re looking for)
We’re now 2 years in to the product being live and people have used Jam to fix more than 2 million bugs - which makes me so happy - but there’s still a ton to do. I wanted to open up for discussion here and get your feedback and opinions how can we make it even more valuable for you debugging?
The worst part of the engineering job is debugging and not even being able to repro the issue, it’s not even really engineering, it’s just a communication gap, one that we should be able to solve with tools. So yeah excited to get your feedback and hear your thoughts how we can make debugging just a little less frustrating.
(Jam is free to use forever — there is a paid tier for features real companies would need, but we’re keeping a large free plan forever. We learned to build products at Cloudflare and free tier is in our ethos, both my co-founder and I and about half the team is ex-Cloudflare) and what we loved there is how much great feedback we’d get because the product was mostly free to use. We definitely want to keep that going at Jam.)
By the way, we’re hiring engineers and if this is a problem that excites you, we’d love to chat: jam.dev/careers