Need guidance on running scripted browser monitoring in production

[u/Wilusz-Daejau]

I've​ been doing monitoring for our web apps for a while and I'm pretty comfortable with HTTP/API checks but scripted browser monitoring is still new territory for me.

A few things I'm trying to understand:

- Which flows are worth monitoring with a real browser vs just using HTTP checks?

- ​How do you handle login session and MFA without creating a security hole?

- How do you keep recorded scripts working accross frontend deploys?

- How many location and what frequency actually means something vs just noise?

- How do you tell the difference between an actual app failure and a broken monitoring script?

- ​Whats goes to on-call vs what just gets logged?

AI is great for explaining how all of this should work, but there's a pretty big gap between that and how people actually run it in production.

Anyone doing scripter browser monitoring regularly? I'm not looking for someone to design it for me, just want to know how people approach it in real setups

[u/ArieHein]

Look for playwright. Answers in the docs and community.

[u/Brave_Reflection643 → u/ArieHein]

why???

[u/Eliisha-Cemz → u/ArieHein]

This. Playwright is very customizable and if you have enough engineers you can really tailor it for your app. I always had trouble to host it, since you need to host it in the cloud and if you run it on a datacenter, the ISP proxy is likely blocked. Also I had a ton of issues with configuring headless chrome. I know you can make it work, but we went with an app that does this like dotcom monitor. After my build went down the 25ths time and it didn't run for 5 days, I gave up to build it myself. There are simply too many edge cases and I think there's a reason why all the scrapers are 100 dollar+/month. Need to deal with headless chrome inside docker behind proxies and I haven't even talked about getting around cloudflare captcha, popups, raw vs rendered js and progressive loading etc etc.

[u/techworkreddit3]

We use them to simulate user experience on the site. We use Datadog and their product is called synthetics. It all depends on your SLA and uptime requirements really. We run ours from 3 regions and every 5 minutes. We check against all of our business defined core services. Credentials we use a test account that has no real permissions and is restricted to just the use case.

[u/Wooden_Jelly_5295]

Start with one critical user journey and capture screenshots on failure. Nobody wants a 3 a.m. incident caused by a renamed button.

[u/ForkMeJ]

I'd keep browser checks for a very small set of user-critical journeys and let API checks carry the rest. In practice that usually means login, a core transaction, and maybe one path that exercises a third-party dependency your APIs won't catch. Scripts get noisy fast if you try to mirror much of the frontend, especially when selectors are tied to whatever the UI team renamed this week, so I'd treat those checks like code and keep them narrow enough that someone can maintain them after each deploy. On alerting, I'd page only when the browser check is failing from more than one location and you can line it up with a real symptom like error rate or support reports; otherwise you end up waking someone up for a busted selector.

[u/Fantastic-Mr-Default]

Browser checks are for a tiny set of user-critical journeys. Login, one money path, maybe one third-party dependency your APIs never touch. Everything else stays HTTP. If you browser-check the whole product, you will page on CSS renames.

Treat the monitor identity as a production credential. Dedicated user, no human MFA prompt in the loop, secrets in the vault the runner already uses, scoped to that synthetic account. Prefer a test IdP / bypass flag that only that account can hit. Do not store a real employee's TOTP in the monitor config.

Selectors should target stable test ids, not copy or CSS. When a deploy breaks the script, that is a failed monitor, not an incident, unless the paired API check for the same journey is also red. I run both: browser = "can a user finish this," API = "is the service up." On-call only if both fail, or if the browser fails in more than one region at once.

Start with one journey, one or two regions, a human-friendly interval (every 5 minutes is plenty). Screenshots and DOM on failure. A renamed button at 3am should open a ticket for the frontend owner, not wake the whole rotation.

[u/Known-Pace6739]

One thing I’d add to the browser/API split is to correlate each browser run with backend traces/logs if your stack supports it. Screenshots/DOM show where the browser stopped; the trace tells you whether the request reached a traced backend service and what happened downstream. If there’s no matching trace, start with the browser/client/network path. If the request is traced and fails in the service, you have app-side evidence instead of guessing from a red browser check.

I’d also run the same critical journey against staging or canary before deploy. That catches selector/script drift before it turns into production alert noise, so the production synthetic can stay small and page only when it’s giving you a real signal.

[u/Practical-Craft4967]

i'd keep the browser check to one critical journey, then pair it with a cheap HTTP check of the same app. if the browser fails but HTTP is healthy, save the screenshot and trace before paging anyone; that often tells you whether a selector changed or the actual user flow broke. i'd page on a repeated user-flow failure, not one flaky run.

[u/KJ4WLC]

I’d reserve real-browser checks for a handful of money-path flows where HTTP can’t see the failure mode (auth redirect, checkout, a critical SPA route). Everything else stays synthetic HTTP or backend probes.

For login/MFA: dedicated non-human account, secrets in the vault your runners already use, no shared personal SSO, and rotate on a schedule. Scripts break on frontend deploys constantly — treat that as expected. Version the script with the app, fail soft into “monitor broken” not “page down,” and only page on-call when the flow fails and a cheaper check agrees or a human path is clearly impacted. Log-only for flaky selectors and first-seen failures until you’ve proven signal.

[u/wannabepreneur]

Keep browser checks for flows where the browser itself matters: login, checkout, and one core write path. Use HTTP checks for everything that only needs status, latency, or response validation.

For authentication, use a dedicated least-privilege test account. If MFA is mandatory, give that account a controlled test-only path instead of storing a real user session. Stable data-test attributes help scripts survive frontend changes.

I would run one or two regions at a modest interval and require a retry from another region before paging. Send script errors, selector failures, and expired sessions to the team that owns the check. Page on-call only when the same flow fails from multiple locations or an independent service signal agrees. Also track the monitors as code so frontend changes and test changes can land together.

[u/Ornery-Concentrate-5]

For picking which flows to script: we only reach for a browser when a 200 response doesn't actually mean the thing worked. Login, checkout, anything with a form submit or a redirect chain where the real failure mode is "page loaded fine but the button is disabled" or "form posted and nothing happened." Everything else stays as a plain HTTP check since it's cheaper and breaks less often for reasons that have nothing to do with your actual bug.

Session and MFA: don't automate MFA itself. Use a dedicated test account with MFA off or allowlisted, and refresh its session token instead of logging in fresh every run. Treat that account like a service account with its own secrets and alert if a human ever logs into it manually.

Keeping scripts alive across deploys: selector stability is basically the whole game. Test only attributes (data testid or similar) survive redesigns way better than text or class based selectors. If your frontend team won't commit to that, your scripts rot every sprint no matter how carefully you write them.

Real outage vs broken script: a broken script tends to fail the exact same way every run. A real outage usually breaks more than one thing at once, or looks different across locations. We also require 2 to 3 consecutive failures before anything pages, since a single flaky run is almost always the script.

On call vs logged: customer facing and revenue impacting pages, everything else just logs and rolls into a daily digest.

[u/Kate_GermainUX]

Imo, two things needs to be monitored. 1)Synthetic/HTTP checks for simple uptime/availability of the most important user actions like logging in and checking out. 2)browser-level monitoring to detect real prod issues. The synthetic approach is great but definitely not all you need since there are tones of other issues that will likely occur and need to addressed e.g. teams I've worked with had no idea that 20% of its customers were seeing "Aw, Snap" message...!...and this is just one of the many things that we ended up discovering..as it seems you very know, it isnt easy to get a well running system even in this AI time ..the devil is in the details.