Record Browser Flows and Monitor Them Automatically

What the Chrome DevTools Recorder is

Since late 2021, Chrome ships with a built-in recording tool: the Recorder (accessible via F12 → "Recorder" tab). Without extensions and without installation, it records user interactions — page loads, clicks, text inputs, wait times — and saves them as structured JSON. Originally designed for developers who wanted to replay tests directly in the browser, the format has established itself as a universal standard for browser automation.

The decisive advantage over manual step configuration: you don't need to copy CSS selectors from the DOM. The Recorder automatically identifies the most stable selector for each element — and you simply click through the page like a normal user. This lowers the entry barrier for synthetic browser monitoring significantly compared to tools that require programming knowledge.

Step 1: Record a flow with the Recorder

Open the target page of your flow — for example the login page or the shopping cart. Then:

1. Open DevTools: Press F12 or Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (Mac).
2. Select Recorder tab: Click "Recorder" in the top tab menu of DevTools. If not visible, find it via the three-dot menu → "More tools" → "Recorder".
3. Start new recording: Click "Create a new recording", give it a name (e.g. "Checkout Flow") and click "Start recording".
4. Walk through the flow: Navigate through the entire process — open page, fill fields, click buttons, wait for confirmation page. Every interaction is captured automatically.
5. Stop recording: Click "End recording". The Recorder now shows the recorded steps with their selectors and values.

Step 2: Export the recording as JSON

After stopping the recording, you can export it directly as a JSON file:

1. Click export button: In the Recorder panel, click the download icon (arrow pointing down).
2. Choose format: Select "JSON" (not Puppeteer or other formats).
3. Save file: The .json file downloads — it contains all steps with selectors, values and timing information.

The exported file contains a standardized format with a steps array where each step has a type (e.g. navigate, click, change) and its parameters (URL, selector, value). XICTRAQ understands this format directly — no manual adjustment needed.

Step 3: Import JSON into XICTRAQ

In the XICTRAQ dashboard, navigate to Browser Monitoring and create a new monitor. Import works in two ways:

• Drag and drop: Drag the JSON file directly onto the page. The importer automatically recognizes the Chrome Recorder format and converts the steps.
• Upload button: Alternatively, click "Import JSON" and select the file from your filesystem.

The importer automatically converts Chrome Recorder steps to XICTRAQ's step format: navigate becomes goto, click stays click, change becomes fill, wait times become wait_for. After import you see all steps in the Step Builder — a visual interface where you can reorder steps via drag-and-drop, delete individual steps or add new ones.

Step 4: Add assertions and activate the monitor

After import, XICTRAQ offers quick assertion buttons after each step. With a single click you add a check:

Typical assertions for common flows:

• Login flow: After submit, assert_url on /dashboard or /account + assert_text on the greeting text.
• Checkout flow: After purchase, assert_text on "Thank you" or the order number + assert_url on /order-confirmation.
• Contact form: After submission, assert_text on the confirmation message — e.g. "Message sent".
• Search: After search input, assert_text on a known result that exists in the database.

Once assertions are in place, select the check interval (5, 15, 30, 60, 180 or 720 minutes) and activate the monitor. The first run starts immediately — via the "Run Now" button you can follow the result in real-time.

What happens when a step fails?

When a step fails — whether a timeout, a missing selector or a failed assertion — the following happens:

1. Failure screenshot: XICTRAQ automatically captures a screenshot at the moment of failure. You see exactly what the browser displayed at that point.
2. Alert on all channels: The error message (including step number and description) goes to all configured alerting channels — email, Slack, Discord, Microsoft Teams, Telegram or webhook.
3. Run history: Every run is logged with per-step timing. You see at a glance which step took how long and where the flow broke.
4. Deduplication: XICTRAQ suppresses identical alerts for 10 minutes so an intermittent failure doesn't flood your inbox.

The synthetic monitoring market grew to 1.48 billion US dollars in 2025 according to Precedence Research, projected to reach 3.36 billion by 2035 — a sign that more and more organizations recognize the value of automated browser checks. Teams without monitoring discover outages an average of 15 to 45 minutes later than teams with active monitoring (Uptime Institute). With average downtime costs exceeding 14,000 US dollars per minute (Gartner/ITIC), that delay adds up quickly.

Practical tips for stable flows

A browser monitor is only as good as its selectors and flow design. These tips help avoid flaky tests:

• Use stable selectors: CSS classes from CSS-in-JS (e.g. .css-1a2b3c) change on every build. Use data-testid attributes or fixed IDs instead — it's a 5-minute fix in the code.
• Add wait steps: Before every click on a dynamically loaded element, insert a wait_for step. Single-page apps need time to hydrate.
• Dedicated test accounts: For login flows, use a separate account with minimal permissions — not the admin login.
• Short, focused flows: Three monitors with 5 steps each are better than one with 20 steps. Shorter flows are more stable and error localization is clearer.
• Match interval to criticality: Checkout every 5 to 15 minutes, newsletter signup every 60 minutes — not everything needs maximum frequency.

Working together with uptime and API monitoring

Browser monitoring complements uptime monitoring and API monitoring — it doesn't replace them. The division of labour:

The combination covers all layers: uptime detects server failures instantly, API monitoring finds broken endpoints, and browser monitoring catches everything that only becomes visible in a real browser — broken JavaScript bundles, faulty third-party integrations, broken CSS selectors after a redesign. All three run on the same XICTRAQ platform with unified alerting.

Technical details: How XICTRAQ executes flows

Every browser monitor runs as a Playwright Chromium session on EU-hosted servers in Nuremberg (Hetzner). This means:

• Headless Chromium: A full browser without GUI — with JavaScript, cookies, localStorage and DOM. Behaves like a real user.
• Anti-analytics: The runner automatically blocks the XICTRAQ tracker so your reach measurement isn't polluted by test pageviews.
• EU hosting: All checks run exclusively on German servers. No data leaves the EU.
• Queued execution: When using "Run Now", the run is queued and begins within seconds. The page auto-reloads once the result is available.
• Per-step timing: Every step is measured individually — you see not just whether but also where a flow gets slow.

From recording to production monitor in under 10 minutes

The combination of Chrome DevTools Recorder and XICTRAQ lowers the entry barrier for browser monitoring to a minimum: no Playwright scripts to write, no test frameworks to configure, no CI pipeline to set up. You click through your website, export the recording and import it — the platform handles the rest. Every few minutes a real Chromium browser drives through the same flow and alerts when a step breaks. The demo shows the entire process interactively, and on the pricing page you'll find browser monitoring starting from the Business plan.