Replay QA acts like a swarm of seasoned app testers. Give it the live URL for a web app, or a localhost URL, and it magically figures out the user journeys, sets up tests and interacts with your app. It’s all captured as deterministic runtime recordings which are then analyzed to find and report bugs.
This is the 4th launch from Replay. View more
Replay QA for Teams
Launched this week
Replay QA tests your web app like a real user, uncovering broken flows, UI issues, and bugs before they reach customers. It gives you the context behind each issue, plus suggested fixes. What's new: With shared projects, teammate mentions, localhost testing, and QA checks on every pull request, your whole team can catch and fix problems before shipping.
Launch tags:Developer Tools
Launch Team / Built With
Jam
MentionDrop
Hey Product Hunt,
Marcos here from @Replay
Last time we launched Replay QA, the most common feedback was the same: "How can my team use this?"
Most production code is AI-generated now, and most tests are written by the same AI. CI goes green. The app looks done. Then someone opens it in a real browser.
That's why we built Replay QA. Give it a URL, and it explores your app the way a new QA hire would, no spec, no one to show them around. It clicks through your app in a real browser, then reports what broke, where, and with root cause detail and a suggested fix. Every session is recorded with our time-travel debugger so you can replay the exact moment something went wrong.
This launch is about teams:
PR checks - Replay runs on every PR, catching issues before merged. It posts debugging context right into the comments. No CI config.
Team projects - invite teammates, share findings, @mention in bug reports.
Localhost support - check before you push. You drop in a localhost URL, and we walk you through the reverse proxy setup - everything configured with you.
Drop in your local or live project URL, then connect GitHub to auto-retest on deployments or PRs.
If your app is posted publicly, it's free to test. Try it at: qa.replay.io
We'll be here all day answering questions about PR checks, how QA fits alongside testing tools, and - if you have an app you'd love us to test.
Thanks to everyone who gave us that feedback and to the beta testers who told us when we were wrong.
Replay
@mplacona @tehreem_fatima5 You can configure credentials for a project, which can be used to test signed-in areas. You can also instruct Replay to run against multiple sets of credentials
Replay
@mplacona @tehreem_fatima5 you can also let the QA agent create their own accounts, but if you have specific test accounts that are in certain states (ex: Admin user vs. normal user) then, as @phazonoverload wrote, you can provide them. It's quite flexible.
Replay
@mplacona @tehreem_fatima5 I've had good success with setting up my PR preview envs so that they use https://github.com/vercel-labs/emulate for the login. This allows PRs to test using several different accounts easily.
Here is an example of "login with linear" being emulated.
https://qa.replay.io/projects/proj-broken-linear-qa-localhost-20260722-mrw4p4rq/journeys/journey-mrw5hvng-mof9?run=ts-mrw4p56f-o2mm
This is generally how I solve it for apps that only have OAuth logins. But for normal username and password login you can just provide the test account credentials and we will use those when testing.
Replay
@vishwa_teja_kondi I'm not 100% clear on what you are referring to. What is the "mini app" you are describing?
Replay
🚨 Looks like GitHub is experiencing issues again today... if you're running Replay QA connected to a repo (and if you're pushing bug reports to GH Issues), you might encounter some weirdness. https://www.githubstatus.com/ (we're keeping an eye on things)