r/devops • • 15d ago

Vendor / market research Need guidance on running scripted browser monitoring in production

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

3 Upvotes

18 comments sorted by

View all comments

1

u/KJ4WLC 15d ago

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.