Replay
Your time travel debugger
665 followers
Your time travel debugger
665 followers
🔴 Record your website in the Replay Browser ⠀ 🔍 Inspect the replay with familiar devtools ⠀ 👋 Share with friends and submit the best bug reports⠀ ⠀ ▶️ Replay captures all of the context needed to replay and inspect the web.⠀
This is the 3rd launch from Replay. View more
Replay QA
Launched this week
Add your GitHub repo for continuous testing, or drop in a URL for a one-time check. Replay QA explores your app, records every session, finds real bugs, and gives your coding agent the root cause and fix. Try for free: qa.replay.io
Free
Launch Team / Built With
had the opportunity to collaborate on this launch and am blown away by how fast the first-time experience is 🤯
go to qa.replay.io and get your first report in seconds.
what's the model you're using in the background, ?makers?
Replay
@fmerian Like most teams, we're using many models in the background as we evolve our QA harness to ensure we're using the right one for the job at hand, and to manage token burn. I'll let Brian chime in here on more technical details once it's morning on the West Coast (still 5am for him!).
@thomascdaly particularly curious if you're using both frontier and open-weight models in prod 👀
Replay
@thomascdaly @fmerian We're mainly using open weight models
The recorded session + root cause combination is what makes this interesting. finding that something broke is useful, but giving a coding agent the exact interaction, state, and context that caused it could remove a huge amount of back-and-forth between QA and engineering.
The first-time experience also sounds almost suspiciously fast :)) Curious how Replay QA handles flaky or environment-specific behavior. can it tell the difference between a real product bug, a temporary network issue, and something that only breaks under one browser or session state?
MentionDrop
@andrasczeizel One of the coding agent patterns that seems to work really well is having one AI do the work and validate itself then pass it's solution to a critic. The critic then looks at the artifacts and tears them apart. Most loops today just pass the code, some better ones will pass screenshots and logs, but passing a full deterministic recording that says "I believe this user session proves this works" seems to be best for the critic.
We have been working on making this as smooth of an experience as possible. Having a deterministic recording of a flake is one of the easiest ways to tell. One of the reasons engineers hate flaky e2e test is because there is no good way to inspect the CI run to tell if it was just a flake or something more important which leads to long investigations which end with you just rerunning the job. Deterministic recordings of the browser sessions and an AI to triage them removes almost all that pain.
@andrasczeizel thank you for giving @Replay a try! feel free to add your review here: https://www.producthunt.com/products/replayio/reviews/new
@andrasczeizel what should they build/improve/fix from your perspective?
@fmerian From my perspective, the biggest opportunity is making the "why" behind every failure impossible to miss.
I would love to see Replay QA automatically classify whether something looks like a product bug, flaky test, network issue, or environment-specific failure, then show the exact evidence behind that conclusion: the relevant state change, request, console error, DOM difference, and what changed across reruns. A simple confidence score plus "reproduce in another browser/session" would make the result much easier to trust and act on.
The product already seems strong at recording the failure. turning that recording into a very clear, developer-ready diagnosis would probably be the thing that makes teams keep using it every day :)
Congrats on the launch, this is a sharp read on where QA broke down — AI cut build time to hours and testing never caught up. We ran into something similar: half our early bugs only showed up after the flows ran a few times, never on the first pass. The GitHub PR flow is the part I keep coming back to — root cause + fix posted right on the PR. How do you handle false positives from apps that behave non-deterministically (race conditions, flaky async UI)? Does Replay QA re-run a failure before flagging it, or does that triage still land on the dev?
MentionDrop
@saied_alimoradi Replay doesn't need to re-run a failure to debug a race condition because it has the conditions which cause the race recorded.
When you have a bug which is a race condition and you submit a fix for that bug we will look at the recording in the bug and faithfully re-create the conditions which caused the race to make sure the new code actually exercises the fix before marking the bug done.
Likewise. From my perspective, this makes @Replay especially useful for engineering teams using products like @Cursor , @Claude Code, or @v0 by Vercel, who need better browser context for debugging.
This feels like a natural next step from the replay/devtools side, turning session capture into something that actively goes and finds bugs instead of waiting for a user to hit them. Since it's exploring the app on its own, is it built to dig into things like auth boundaries and cross-user data isolation too, the bugs that never throw an error and just quietly leak or drop data, or is the current focus mostly on crashes and broken UI flows? That category is brutal to catch in vibe-coded apps and it would be a big deal if an agent could reliably surface it.
MentionDrop
@elhart05 spot on! To quote @Product Hunt's newsletter today:
Read on: The Leaderboard, July 20, 2026
the recorded-session-to-root-cause handoff is the interesting part, most QA tools stop at "here's a broken screenshot" and this closes the loop back to something a coding agent can actually act on. one question I didn't see covered above: when the agent auto-explores an app that has real user data behind auth (not just a throwaway account), what happens to whatever it touches or records during that exploration - is there any scrubbing/redaction of sensitive fields before a recording gets stored, or is it on the team to only ever point it at a sandboxed environment?
Replay
@galdayan for apps that have sensitive data, the team testing it should give it a sandboxed account.
Replay
@ridhwikvinod this is exactly why teams that have apps which hold sensitive data create a sandboxed version with dummy data. This gets around the “stored PII” issue. It’s also how teams handle QA testing for apps hosted on private networks.
The "gives your coding agent the root cause and fix" part is what stands out to me — most QA tools stop at "here's a failing session," this one seems to actually close the loop back into the fix. Did you find agents act on that context reliably, or does it still need a human to sanity-check the suggested root cause before it gets applied?
MentionDrop
@av777a spot on! @Replay definitely is an opinionated piece of software. S/O to makers @bhackett1024 @thomascdaly @mplacona and team!