Four journeys decide whether your product works

Start with the ones that generate a support ticket when they break: signing in, signing up, and whatever your product’s core action is — placing an order, sending a message, running a job. Three or four well-chosen flows catch most of what matters. Breadth comes later; depth on the critical path comes first.

Use a dedicated probe account rather than a real customer’s. Credentials live in encrypted environment variables, and for time-based second factors you can generate the code at run time from a seed stored the same way. Session reuse is available too, though for a login flow the point is usually to exercise the whole authentication path every run.

It will if you do nothing about it, so filter it. Send a known user agent or header from your checks and exclude it in your analytics tool, use a dedicated probe account you can filter on, and point transactional steps at test mode or a test SKU. This is worth deciding before the first check goes live, not after.

Frequently enough that the detection window is shorter than your tolerance for the outage. Every five minutes is a common starting point for a login or checkout flow, with the underlying APIs checked every minute. Raise it during a launch or a peak period and lower it for flows where a longer gap is genuinely acceptable.

The run captures a full screenshot, a video replay, and a trace, with each step timed separately, so you can see whether the second factor timed out or the dashboard rendered empty. AI root cause analysis reads that evidence and summarizes the likely cause before anyone opens the recording.

Yes, and they are the right flows to drive it. A status page built on “the site returns 200” is the one that says everything is fine while nobody can log in. Wire the flow checks to a status page on your own domain and the incident opens when the login or checkout check fails, notifies subscribers, and resolves when it recovers, so what customers read matches what your users are actually experiencing.

Retry from a different region before alerting. Every failed run can be retried with fixed, linear, or exponential backoff, from the same location or a different one, so a regional network blip resolves itself. For checks running in parallel across locations you can also require a percentage of locations to fail before anything fires, and route degradation to a different channel than outright failure.

Yes, and teams usually do. The same spec runs against a preview URL in CI to gate the merge and against production on a schedule afterwards, with the target injected as an environment variable. One suite, two jobs, no second set of tests to keep in sync.