Why Traditional Synthetic Monitoring Breaks
The promise is real: instead of waiting for a customer to email you that they can't complete a purchase, a synthetic monitor catches it first. It simulates a real user, navigating, clicking, filling forms, checking out, and alerts you the moment something fails. That's genuinely valuable, especially for agencies managing sites where downtime means lost revenue.
The reality is messier. Traditional synthetic scripts are imperative code. They say *exactly* which element to click, by exact selector. `#checkout-btn`, `.product-card:nth-child(3) > button`, `[data-testid="submit-order"]`. The moment a developer touches that markup your monitor breaks.
This isn't a hypothetical. It's the norm. A site redesign, a framework upgrade, an A/B test that changes button classes, any of it kills your monitors. And maintenance doesn't scale. If you're an agency managing twenty client sites, you're not maintaining one test suite. you're maintaining twenty, each with its own stack, design system, and deployment cadence.
The compounding problem is alert fatigue. When monitors fire false positives constantly teams start ignoring alerts. And then when the actual checkout breaks, it sits there broken until a real user reports it. I've seen this play out repeatedly. The monitors were there, they were firing, and nobody looked because they'd been crying wolf for months.
Basic uptime monitoring isn't sufficient here either. a 200 response from your homepage tells you nothing about whether the purchase flow actually works.
What AI-Powered Synthetic Monitoring Actually Is
Traditional synthetic monitoring is imperative: *click this exact selector*. AI synthetic monitoring is declarative: *click the Add to Cart button*.
The difference sounds small. It isn't.
With an LLM-driven browser agent, you describe your *intent* in plain English and the AI resolves it against the actual page at runtime. It analyzes the DOM, interprets visual layout and context, identifies the element that best matches your description, and executes the action. No hardcoded selectors. No tightly coupled test code.
This resilience comes from how the AI understands elements. Not by matching a string, but by understanding context. If the "Add to Cart" button changes from a green `.add-btn` to a blue `.product-action-primary`, the AI still finds it because it understands what "Add to Cart" means on a product page. A CSS selector might break.
One thing worth clarifying: AI synthetic monitoring is not a replacement for unit tests or integration tests. It's production journey verification. You're not testing code, you're verifying that real user journeys work right now, in the real environment, with real infrastructure. Different job, different tool.
The mental model shift is from "writing test scripts" to "describing user journeys." That distinction matters for everything that follows.
Anatomy of a Great Plain-English Flow Definition
Every step in a well-designed flow has three components: an *action (what to do), a target (what to interact with), and an optional assertion. When any of these are ambiguous or missing, you get flaky monitors.
Be specific about intent, not implementation. There's a meaningful difference between these two descriptions of the same action:
Type [email protected] into #email-inputFill in the Email field with [email protected]
The first breaks the moment the input's ID changes. The second is tied to the label text, which is stable because it's what users see. UX copy changes far less often than DOM structure.
Always include explicit assertion steps. Don't assume navigation happened, verify it.
Go to https://example.com/checkout
Fill in the Email field with [email protected]
Fill in the Password field with [TEST_PASS]
Click the Sign In button
Verify the page shows "Welcome back" or displays an account dashboardKeep steps atomic. One action per step. When a flow fails, you want to know exactly *which* step failed, not that "something in the checkout sequence went wrong."
Here's a complete five-step checkout flow with annotations:
# Step 1: Navigate and verify we're on the right page
Go to https://shop.example.com/products/test-product
# Step 2: Add to cart, reference the action intent, not the button's class
Click the Add to Cart button
# Step 3: Explicit assertion before proceeding
Verify a cart notification appears or the cart count increases
# Step 4: Proceed to checkout
Go to the checkout page or click the Proceed to Checkout button
# Step 5: Verify we reached checkout and don't assume the click worked
Verify the page shows a checkout form with an email fieldThe comments here are for your benefit, but the principle they illustrate is real. Each step is checkable in isolation. If step 3 fails, you know add-to-cart is broken. If step 5 fails, you know the checkout navigation is broken. Atomic steps make triage fast.
I built Vigilant with exactly this approach in mind. It's Flows feature lets you define steps in plain English like this, and an AI agent executes them in a real browser. No test framework, no selector maintenance, no Playwright configuration and no AI setup.
Handling Authentication and Session State
Authentication is where a lot of synthetic monitoring setups fall apart. Here's what I've learned works.
Use dedicated monitoring credentials. Never use real user accounts for synthetic monitors. Create accounts specifically for monitoring, `[email protected]`, with known, stable state. Real accounts accumulate order history, loyalty points, and other state that can make flows unpredictable.
Fresh login per run is more reliable than session reuse. Yes, it's slower. But reusing cookies means you're one session expiry away from cascading failures across every authenticated flow. The overhead of a fresh login is worth the reliability.
MFA and 2FA require a deliberate strategy. Options in rough order of pragmatism:
Whitelist monitoring infrastructure's IP addresses to bypass 2FA
Create monitoring accounts with 2FA disabled
Build a monitoring-specific auth endpoint, acceptable if you control the codebase and can secure it properly
CAPTCHAs are a related problem. Whitelisting your monitoring IPs is usually the cleanest solution. Alternatively, most platforms have test modes or environment flags that disable CAPTCHA for known non-human traffic.
Putting It All Together: A Complete Flow Monitoring Setup
Let's walk through how I'd set this up for a WooCommerce client. The principles apply equally to Magento, Shopify Plus, or any other e-commerce platform.
Identify the five critical journeys first. For most e-commerce sites, that's: homepage to product to cart to checkout, login, site search, contact form, and account area access. These are the flows where a failure costs money or destroys trust.
Write flow definitions using the patterns above:
# Critical: Checkout Flow
Go to https://client-store.com/shop/monitoring-test-product
Click the Add to Cart button
Verify the cart count increases or a success notification appears
Go to https://client-store.com/cart
Verify the test product appears in the cart
Click the Proceed to Checkout button
Verify the checkout form is displayed with an email field
# Critical: Login Flow
Go to https://client-store.com/my-account
Fill in the Username field with [MONITOR_EMAIL]
Fill in the Password field with [MONITOR_PASS]
Click the Log In button
Verify the page shows "Hello" or displays a My Account dashboard
# Warning: Search Flow
Go to https://client-store.com
Fill in the Search field with "test"
Press Enter or click the Search button
Verify search results are displayedConfigure test infrastructure before running anything in production. Create the `[MONITORING]` test product, set up dedicated credentials, add your monitoring IP to any CAPTCHA or 2FA allowlists.
Build a review cycle. After any significant site redesign or feature launch, review your flow definitions. You'll update them far less often than you would coded scripts, but they're not completely maintenance-free. Treat it like updating documentation, not debugging code.
Introducing Vigilant covers the full platform if you want to see how flow monitoring fits alongside uptime, performance, and security monitoring, all from one self-hostable tool purpose-built for agencies managing multiple client sites.
From Flaky Scripts to Reliable Journeys
The shift from scripted synthetic monitoring to AI-powered flow monitoring isn't just a technical improvement, it's a different way of thinking about the problem. You're not writing test code anymore. You're describing what a user does and what success looks like. That description is durable in a way that imperative selectors never will be.
The principles that matter: be declarative, use business-domain language, keep steps atomic, handle auth with dedicated credentials, design for idempotency, and map every flow to a business severity before you set up the alert.
If you're managing multiple client sites, start with one flow, your most business-critical journey, usually checkout or login. Get that working reliably, with proper severity routing and maintenance window handling. Then expand. The patterns replicate across every site you manage, regardless of the underlying platform.
The goal isn't exhaustive coverage. It's confidence that the journeys that actually matter. the ones where failure costs money, damages trust, or locks users out are working right now.
That confidence is worth more than a thousand unit tests that all pass while your checkout lies broken in production.