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
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.
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)
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.
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.
You are being silly.
That’s a great trick to get the exact time from full screenshot
I really like this idea and if Firefox support was added I would purchase it in a heartbeat.
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
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)
From a funding perspective things are very different than when CF started.
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
Also how future proof it is with Google changing Chrome addons permissions / API etc...?
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.
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.
Edit: it looks like this is already the case!
Yeah, I fell into that trap, but it's a holiday here.
They really should have gone for JSVM IR or something, but that would sell it to no one.
Joking aside, this looks really cool!
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.
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.
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.
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.
It's NOT built for everyone.
Right?
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.
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.
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 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.
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.
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.
[0] https://tailscale.com/blog/sso-tax-cut
[1] https://sso.tax/
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 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!
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'd be pretty annoyed if the bug is not reproducible and I lose that chance of generating a bug report.
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!
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/?
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
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.
- 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)
- 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!
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.
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?
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.
I make beekeeper Studio and struggle with bug reports being very vague
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.
Feel free to reach out and we can give you some free credits to your account: dani@jam.dev
We really just care that we can help you streamline bug reporting, we don’t want the pricing to get in the way.
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.
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.
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)
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.
+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.
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.
Firefox version - totally agree. We have to do it. I promise we will :)
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
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?
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 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.
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.
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.
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 - 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!
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.
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.
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!!!).
> ... 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.
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.
That said, this looks outstanding, it could really be a great option for QA teams.
Edit: never mind - I see this is a browser extension, so kind of a non-starter.
