Replay
Your time travel debugger
667 followers
Your time travel debugger
667 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
Congrats on launching a neat product! Do you guys crawl read-only paths first and earn its way into write actions, or is the expectation that people hand it a scoped throwaway account and let it break things?
Replay
@artstavenka1 When we detect the presence of auth for an app, we ask users how they'd like the Replay QA agent to proceed:
a) Provide specific username/password creds (aka, your scoped throwaway account)
b) Let the agent create its own account(s)
c) Skip auth
As you can imagine, with something as nuanced as auth and the many flavors out there, it can be tricky, but our agent handles it quite well.
@artstavenka1 appreciate the kind words! let's spread the word on X, repost this
the root cause handoff to a coding agent is the part that stands out to me, most bug tools stop at 'here is a recording' and leave you to figure out the actual cause yourself. when it explores the app on its own rather than following a fixed test script, how do you keep it from wasting time down paths a real user would never take?
Replay
@omri_ben_shoham1 what you're asking hits on exactly what we do that sets us apart from anyone else out there. Our initial product captured deterministic runtime recordings, and then gave you the DevTool interface to time-travel the recording to find root cause yourself. We've now given agents the skills and the harness to do the time-traveling for you. Built upon our years of experience building debugging tools, here at Replay, and the 10yrs Brian Hackett (CEO) spent at Mozilla working on their devTools, we learned what agents need to keep them from going down rabbit holes and wasting time. Check out this Timetravelogue deep-dive by Mark Erikson to get a sense of our approach. (Keep in mind, this is Mark using Replay MCP which is now one of the enabling layers of Replay QA)
Post 1: How Replay MCP Helped Find a React Bug Faster than Dan Abramov Did
https://www.replay.io/blog/replay-time-travelogue-how-replay-mcp-helped-find-a-react-bug-faster-than-dan-abramov-did
Post 2: Improving Nadia’s “Debugging with AI” Results Using Replay MCP
https://www.replay.io/blog/replay-time-travelogue-improving-nadias-debugging-with-ai-results-using-replay-mcp
dropping here 2 additional resources re: @Replay MCP
How to set up Replay MCP with Codex in under 10 minutes
How to set up Replay MCP with Claude Code in under 10 minutes
hope it helps, over to you!
@omri_ben_shoham1 hey I work on the replay team specializing in exactly this let me know if you'd like to setup a call to discuss how to make the most use of replay in a typical Builder/Critic feedback loop.
honestly this looks pretty cool, would love to see a way to redact sensitive info like api keys or user emails before sharing a replay. kind of a blocker for shipping these to support or external devs right now.
@semradermat5ca great suggestion! cc @mplacona @thomascdaly
Replay
@semradermat5ca this is why teams that are testing apps which hold sensitive data set up a sandboxed version with seeded dummy db data.
Spycost
Root-cause handoff to coding agents feels genuinely useful. How do you decide which flows Replay QA explores first?
Replay
@glebarios this is handled by our custom-built QA harness. Our QA agent starts by acting as naive as possible, starting with the root page, and analyzing it for what's actually there. With each successive analysis pass, our agent "learns" more and more about what your app is, what it's intended purpose it, and what end-to-end user journeys exists. It then catalogues each user journey, writes Playwright tests against them and executs them by puppeting the app in the browser—all while capturing deterministic runtime recordings (Replay Recordings) that are then analyzed by our agents to identify issues. We have a baked-in triage system that does what human teams do... prioritize what to do first for maximum impact.
@glebarios @thomascdaly for full disclosure, we could add that @Replay might not replace every kind of testing, but it will catch the obvious broken flows before your users, clients, or @Product Hunt visitors do ✌️
The "give your coding agent the root cause and fix" handoff is the part I'm most curious about — I run multiple coding agents on a monorepo and the painful step is always getting the bug reproduced inside the agent's context. Is the handoff a replayable trace the agent can actually step through, or a text summary of the root cause? Congrats on the launch — the drop-a-URL one-time check is a smart low-friction entry point.
MentionDrop
@nitish_garg4 Exactly the right question. The useful handoff is a replayable trace the agent can step through, with the relevant context and state, not a glorified text summary. The goal is to remove the “can you reproduce this?” tax before the agent starts working.
Is there a way to give it a test email to enter a logged-in area of our browser-based software? Without giving Github access, just to act as if it's a real user setting up an account.
@jackson_mclean Username and password auth or magic links are the easiest way to get the AI to login. Just tell the chat "login with this username and password".
If you only have social logins like login with google then we would likely require a staging environment to test against since login with google is built from the ground up to stop bots.
We are working on workaround where we just pull up the browser ask you to login and then the AI picks up from there. Driving an E2E test through a 3rd party production login is an age old E2E testing problem.
Swytchcode
Do we need to write test cases in our GitHub repo, or does the tool help us write the test cases for testing?
How does it work when we have feature updates
Replay
@chilarai the beauty of Replay QA is that you do not need to have even a single test case written in your Github repo. It handles this automatically. We've invested a massive amount of energy in our QA harness so teams don't have to, and can focus on more important stuff.
Swytchcode
@thomascdaly if you have a free plan for OSS projects, we are happy to evaluate
@thomascdaly @chilarai an oss program? love the idea, oss ftw! ping @mplacona @bhackett1024
@chilarai thank you for your continuous support, Chilarai! have you experimented with the tool? would love to have your review here: https://www.producthunt.com/products/replayio/reviews/new
keep up the great work