How to Run Automated Cross-Browser Smoke Checks From n8n

What a Cross-Browser Smoke Check Actually Is

A smoke check is a small, fast suite that answers one question after a build ships: is this stable enough to use? It does not chase edge cases. It confirms the app loads, a user can log in, navigation works, and the core transaction completes. A cross-browser smoke check asks the same handful of questions on every browser engine your users run, not just the one on your machine.

The reason this is worth automating is the cost of letting a broken build sit. The Consortium for Information and Software Quality (CISQ) put the cost of poor software quality in the US at at least $2.41 trillion in its 2022 report, and a meaningful slice of that is failures that reach production and get found by users instead of by a check that runs in minutes.

It helps to place a smoke check next to its neighbors. If you want the full breakdown, see the automated smoke testing pillar and this comparison of smoke testing vs sanity testing.

• Smoke: broad and shallow, run on every build, gates whether deeper testing is even worth it.
• Sanity: narrow and slightly deeper, run after a specific fix to confirm that one area.
• Regression: wide and deep, re-runs the large suite, run nightly or before a release because it takes time.

Why Trigger Smoke Checks From n8n

The key idea is that n8n is the orchestrator, not the test runner. It listens for an event, decides what to fire, branches on the outcome, and notifies people. The browser work happens elsewhere. That separation is what keeps the smoke check simple: n8n owns the "when" and the "what next," while the cloud owns the "run the browser."

n8n is a safe foundation to build on because it is widely adopted and connects to almost everything. Its open-source repository has been forked more than 58,000 times and ships with 400+ integrations out of the box, per the n8n GitHub repository, so your deploy source, alerting channel, and ticketing tool are almost certainly already nodes you can drop onto the canvas.

Choosing n8n over a hand-written CI script comes down to four practical wins:

• Visual control flow: the trigger, the browser run, the pass/fail branch, and the alert are nodes anyone on the team can read, not buried YAML.
• Event-driven triggers: a webhook from your deploy tool starts the check the instant a release lands, no polling.
• Built-in fan-out and alerting: loop a list of browsers and route failures to Slack, email, or PagerDuty without extra code.
• Tool-agnostic: the same workflow works whether you deploy from a Git push, a release tag, or a manual button.

If you are new to using n8n this way, the broader n8n test automation guide covers the orchestration model in depth. It matters because automation coverage is now the norm, not the exception: in the Stack Overflow 2024 Developer Survey, 56.3% of professional developers said automated testing was available within their organization, so wiring a smoke check into the release flow is a natural next step rather than a leap.

How the Workflow Fits Together

The whole thing is a short pipeline. Each stage hands off to the next, and only the last stage talks to humans, and only when something is wrong.

• Trigger: a Webhook node catches the deploy event, or a Schedule node runs the check at a fixed interval.
• Fan-out: a list of target browsers feeds a loop so each browser gets its own run.
• Execute: the TestMu AI Agent node drives a real cloud browser through the critical paths and returns the result.
• Parse: a Code or IF node reads the result and decides pass or fail.
• Alert and gate: the failure branch notifies the team and can signal the pipeline to hold the release.

Running this on every deploy fits how fast teams ship today. In the 2023 Accelerate State of DevOps Report, DORA found that top-performing teams deploy on demand and recover from a failed deployment in less than one hour. A smoke check that runs automatically on each release is what makes both possible, because it catches the break in minutes instead of after a customer reports it. Wiring it into the pipeline is the same pattern as cross-browser testing in your CI/CD pipeline, with n8n as the conductor.

Setting Up the Node and Cloud Browsers

The browser run is handled by the TestMu AI (Formerly LambdaTest) Agent node, a verified n8n community node that drives real Chrome, Firefox, Safari, and Edge in TestMu AI Browser Cloud over the W3C WebDriver protocol. It exposes seven operations an n8n workflow calls in sequence: navigate, snapshot, click, type, get_text, screenshot, and release. For a smoke check you mostly need navigate to open the deployed URL, get_text to assert a critical element rendered, and screenshot to capture evidence.

Step 1: Install the node. On self-hosted n8n, open Settings, choose Community Nodes, click Install, and enter the package name. On n8n Cloud, install it from the Verified Community Nodes marketplace inside the node panel.

# Self-hosted n8n: Settings > Community Nodes > Install
n8n-nodes-testmuai

Step 2: Add your credential. Create a TestMu AI (Formerly LambdaTest) API credential and paste in two values from your TestMu AI profile.

• Username: your TestMu AI account username.
• Access Key: your TestMu AI access key, kept as a secret like a password.

If your build is not on the public internet yet, that is fine: Browser Cloud ships a built-in tunnel so a cloud browser can reach a staging URL or an app behind a firewall, which is exactly where a post-deploy smoke check on a preview environment needs to run. The full node walkthrough lives in the TestMu AI Browser Cloud n8n node guide, and the platform specifics are in the Browser Cloud documentation. Why bother with cloud browsers instead of a single headless instance? Because no build ships perfectly: in the CircleCI 2024 State of Software Delivery, main-branch pipeline success rates reached 82.5%, which still leaves close to one deploy in six carrying a problem worth catching across browsers.

Building the Smoke Check Step by Step

With the node installed, the workflow is a straight line. Start with the trigger, define the browser list, then drive the critical path per browser.

Step 1: Add the trigger. For a post-deploy check, use a Webhook node and point your deploy tool's success hook at its URL. To run on a cadence instead, use a Schedule node. Either way, the trigger can carry the deployed URL as a parameter so the same workflow checks staging or production.

Step 2: Define the browser matrix. Add a Set or Code node that outputs the browsers to cover, one item each, so the next node runs once per browser.

// Code node: emit one item per target browser
return [
  { json: { browser: "Chrome",  url: $json.deployUrl } },
  { json: { browser: "Firefox", url: $json.deployUrl } },
  { json: { browser: "Safari",  url: $json.deployUrl } },
  { json: { browser: "MicrosoftEdge", url: $json.deployUrl } },
];

Step 3: Drive the critical path. For each item, the TestMu AI Agent node opens the URL, confirms a known element is present, and grabs a screenshot. A simple instruction for the agent describes the smoke check in plain steps.

Smoke check task for the TestMu AI Agent node:
1. navigate -> open {{$json.url}}
2. get_text -> confirm the page <title> contains the app name
3. get_text -> confirm the "Log In" button text is present
4. screenshot -> capture the rendered homepage as evidence
5. release -> end the session
Return PASS only if steps 2 and 3 both find their text.

Teams that prefer code can run the same critical path as a Selenium or Playwright script on the TestMu AI cloud grid and have n8n trigger it with an Execute Command or HTTP Request node. The script changes only its endpoint and capabilities; the test logic stays the same.

// Playwright smoke check on the TestMu AI cloud grid
const { chromium } = require("playwright");

const capabilities = {
  browserName: "Chrome",
  browserVersion: "latest",
  "LT:Options": {
    platform: "Windows 11",
    build: "Cross-Browser Smoke Check",
    name: "Homepage critical path",
    user: process.env.LT_USERNAME,
    accessKey: process.env.LT_ACCESS_KEY,
  },
};

(async () => {
  const browser = await chromium.connect(
    `wss://cdp.lambdatest.com/playwright?capabilities=${encodeURIComponent(JSON.stringify(capabilities))}`
  );
  const page = await browser.newPage();
  await page.goto("https://www.testmuai.com/selenium-playground/");
  // Assert a visible element, not the document <title>, so the check reflects what users see
  await page.getByRole("heading", { name: /Selenium Playground/i }).waitFor({ timeout: 20000 });
  await browser.close();
})();

Because every run executes on a real cloud browser, you get a recorded session with the rendered page, console output, and network logs, so a failed smoke check comes with the evidence already attached. The grid below shows the same smoke check passing on real Chrome, Firefox, Safari, and Edge sessions against the Selenium Playground, each captured through the TestMu AI cloud while writing this guide.

Parsing Pass or Fail and Alerting the Team

The browser run returns a result your workflow has to read. Send it into a Code node that normalizes the outcome into a single status field, then into an IF node that branches on it. Keeping the parse explicit means a flaky network blip and a genuine failure are handled differently.

// Code node: normalize each browser result into a status
const failed = items.filter(i => i.json.result !== "PASS");
return [{
  json: {
    allPassed: failed.length === 0,
    failedBrowsers: failed.map(i => i.json.browser),
  }
}];

Wire the IF node so the failure branch posts to a Slack or email node and, if you gate deploys, returns a non-success response to the deploy webhook to hold the release. Catching breakages fast is the whole point: in the 2024 Accelerate State of DevOps Report, DORA measured a 40% change failure rate for low-performing teams, meaning roughly two in five of their deploys introduce a failure that needs immediate attention. A smoke alert is what turns that from a Monday surprise into a five-minute fix.

• Make the alert actionable: include the failing browser, the failing step, and a link to the recorded session so on-call can watch the break.
• Keep the pass branch quiet: silence on green, a single message on red, so the channel stays signal.
• Inspect payloads while building: drop the node output into a JSON viewer to read the pass/fail structure before you write the IF condition.

Choosing Your Browser Matrix and Critical Paths

A smoke check earns its speed by staying small, so cover the engines that actually carry your traffic rather than every browser in existence. The split between engines is real and worth designing around.

As of May 2026, StatCounter put worldwide desktop share at 74.93% Chrome, 9.94% Edge, 5.32% Safari, and 3.81% Firefox, which means roughly a quarter of desktop visits run on a non-Chrome engine. Testing Chrome alone leaves that quarter unverified. On mobile, the same source put Safari at 25.25% behind Chrome, so the engine mix shifts again the moment your users are on phones.

Two rules keep the matrix honest:

• Pick engines, not just browsers: one Chromium (Chrome or Edge), one WebKit (Safari), and one Gecko (Firefox) catch most rendering and scripting differences.
• Pick paths that block a release: load, auth, primary navigation, and the core transaction. If breaking it would stop a customer, smoke-test it; otherwise leave it for regression.

Because TestMu AI offers 3,000+ browser and OS combinations, you can mirror your real analytics, including older versions, without installing a thing locally.

Scaling From a Smoke Check to Full Regression

The n8n smoke check is the fast gate on every deploy. As coverage grows, two things change: the suite gets bigger, and you want it to finish before it slows the pipeline down. That is the point to move execution onto a grid built for scale rather than stretching the smoke flow.

Run the broader suite on the Automation Cloud, which executes your existing Selenium, Cypress, and Playwright scripts in parallel across the browser matrix and captures network logs, console logs, video, and a command replay on every run with no extra setup. When even parallel runs are not fast enough, HyperExecute orchestrates execution up to 70% faster through intelligent test splitting and auto-retry, so a growing regression suite still fits inside a release window.

Keep the division of labor clear as you scale: n8n decides when to run and who to tell, and the cloud grid runs the browsers and records the evidence. That holds whether the suite is five smoke checks or five hundred regression cases.

The reliability payoff compounds with maturity. The same DORA research shows elite teams keep their change failure rate far below low performers, and an automated cross-browser gate on every deploy is one of the concrete practices that narrows that gap. To extend the n8n side further, the n8n AI agents for browser tasks guide shows how to push the same workflow beyond smoke checks.

Conclusion

Start small: install the TestMu AI node in n8n, add your credential, and build a one-browser smoke check that opens your deployed URL and asserts the homepage loaded. Once that is green, add the browser list, the pass/fail parse, and the Slack alert, then point your deploy webhook at it.

That single workflow turns "it worked on my machine" into "it works on every engine our users run," verified on each release with no infrastructure to maintain. Grab your TestMu AI credentials from the dashboard, then follow the HyperExecute getting started guide to wire the cloud run into your pipeline and gate your next deploy on a green cross-browser smoke check.