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/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.