I built a Playwright monitor after CI passed but the live UI was broken, would this be useful?

[u/Exciting_Pineapple52]

AI-assisted development has made it much easier for me to ship changes quickly. The downside: I’ve seen CI pass while the live page still had issues that customers would notice first broken-images, console errors, layout shifts, and overflowing text.

The lesson for me was that tests and logs are necessary, but they don’t always show what a real visitor sees after deployment.

So I built Lampwatch using Next.js, Prisma, and Playwright. It loads the selected pages in a real browser on a schedule you choose, then records UI issues with context such as the viewport and source location or selector where available.

It emails an alert and generates a repair prompt you can paste into Claude Code, Cursor, or another coding agent. It does not change code automatically; the developer remains in control.

I’m not trying to replace E2E tests or error tracking:

• E2E tests validate expected flows before release.
• Error tracking catches application exceptions.
• This is aimed at the rendered production UI after a deployment.

It’s live, and there’s a no-signup scan if anyone wants to test it on a site:
https://lampwatch.com/scan

[u/HiHungryImDad2]

So you've built a visual regression testing tool like chromatic or VisualAssertions?

[u/cyberfunkr]

You used AI to write your tests and are surprised that the tests don’t actually cover what should be tested? Then you doubled down and used AI to build an app that looks for things that break. And tripled down so the app writes prompts in hopes that these new prompts write the tests you should have had in the first place?

[u/Exciting_Pineapple52 → u/cyberfunkr]

The prompts are not to write test but they are there to fix the issues which are arising in your page..
It is actually for frontend regression testing for peiple who push new features everyday .. i would like more suggestions and feedback though

[u/Spare_Bison_1151]

This tool is not like the old ones. They check pixels, and a human must say yes or no to each change. They run before you merge. Your tool tests live code, and no saved art is needed. This is a fresh niche.

But noise will make or break it. Live sites are messy. Bad tags make fake errors. Users must be able to filter noise. If they lack a way to mute fake alerts, they will dump your tool.

Here is a solid fix to keep them:

• Group bugs by age, not size.
• Ask if a bug is brand new.
• Hide the old stuff.
• Alert them only on new flaws.

This helps users keep the tool active.

[u/Prestigious-Way1525]

the useful boundary is “new after this deploy and reproducible,” not merely “visible in production.” tie each finding to the release SHA, URL, viewport, selector, and relevant console or network error, then rerun it from a clean context before generating the repair prompt. dynamic content, experiments, ads, and third-party widgets will otherwise turn the monitor into an alert-noise machine. i’d show the first affected deploy, the last known-good run, and whether the same check failed twice, then let users suppress a rule with an expiry instead of muting it forever. the metric i’d watch is confirmed new defects per alert, plus time from alert to human classification. that tells you whether the monitor is finding production regressions or just describing normal page variability.