How to Find the Root Cause of a Failed Test with AI in Under a Minute

How AI RCA Reads a Failed Test

AI RCA is an LLM-based analysis of a single failed test. It reads the test's logs, screenshots and execution data, points to the file and line where the error occurred, and on HyperExecute it also uses the git data of the repository that triggered the job.

On HyperExecute, the AI-native test failure analysis documentation states that generating an RCA from a failed job's Failure Analysis tab usually takes around 20-30 seconds.

TestMu AI positions its AI test failure analysis as a lead to verify: RCA correlates the run's network, console and framework logs to localize a likely cause, and an engineer confirms it before acting. Runs that captured those logs give it more to work with.

You can generate AI RCA on HyperExecute jobs and Test Manager runs, trigger it by test ID for Web and App Automation sessions through the API, and read its trends in Insights. A failed KaneAI test run has its own Generate RCA button that examines the failure context and suggests probable causes. If you want the manual methods behind it (the 5 whys, fishbone diagrams, defect-level RCA), the guide to root cause analysis in software testing covers them.

How to Capture the Evidence RCA Needs

An RCA is only as good as the run it reads, and several of the most useful logs are off by default. The debugging options documentation describes what each log type records, and the Selenium automation capabilities reference lists the capability that turns each one on, with its default and limits. Set them before the failure you want explained.

A good default for test observability on a suite you plan to analyze: keep video on, turn on network and console logs for the failing projects, set a remark with the assertion message when a test fails, and leave collectLocalGitData alone so the analysis can tie a failure back to a change.

How to Generate an RCA From a Failed HyperExecute Job

Manual RCA needs no targeting rules. It works on any failed test once the account has a HyperExecute or Web/App Automation plan, access to Insights and enough credits. On HyperExecute, the test-level path runs through the job's Tasks tab:

• Open the failed job from the HyperExecute dashboard. The header shows the Failed status and the job duration, plus the git commit when the job was triggered through Workflows or sourcePayload.
• On the Tasks tab, select the failed execution task and open Scenarios.
• Find the failed test and click Generate RCA, next to its duration.
• Read the RCA panel that opens, from the classification down to the fix steps.

HyperExecute has more entry points. The job's Failure Analysis tab (still labelled Beta) has its own Generate RCA button, the one TestMu AI's documentation times at around 20-30 seconds, and it groups the job's errors by category with Remedies and Additional suggestions for each. From a scenario log, the Errors icon > See Details opens the line number, code snippet and stack trace, with Generate RCA further down.

These keys in hyperexecute.yaml shape what the job hands to the analysis and what it exports afterwards:

# hyperexecute.yaml (excerpt)
collectLocalGitData: true             # default; git data used in AI RCA generation
errorCategorizedReport:
  enabled: true                       # downloadable report of failures grouped by error category
errorCategorizedOnFailureOnly: true   # categorize only the stages that did not pass

The error categorization report is generated for a failed job that includes multiple error categories. It lists each error summary with its details and does not depend on the report: true flag, which makes it the artifact to attach to a ticket when a job fails for several different reasons.

How to Read the RCA Panel

Clicking Generate RCA on a failed test in the HyperExecute Tasks tab or a Test Manager run opens the RCA panel. Read it top to bottom, and act on each section before moving to the next:

In the documentation's sample above, the test failed while locating an element, but the analysis traced it to an uncaught TypeError at products.js line 156. The page component never rendered, so the element never existed. The timeline tags the element lookup as the Root Cause event and the two later failures as Effects, and the fix is a null check before calling map() on the product data. Changing the selector would not have fixed it.

A Real Failed Run, From Red to Cause

For this guide, two deliberately broken Playwright tests ran on the TestMu AI Automation grid (latest Chrome on Windows 11) against the Selenium Playground, in a build named "RCA use case artifact 2026-09-28". Each has a planted cause, which makes the pair a calibration set: you know the right answer before any AI reads the logs.

• Simple Form Demo echoes the message - The test expects "Welcome to TestMu AI!" and the page echoes "Welcome to TestMu AI". It failed after 1.9 seconds, and the cause is the expected string in the test.
• Ajax Form Submit sends the form - The test clicks #submit-button, but the page's button is #btn-submit. It failed after 21 seconds with page.click: Timeout 10000ms exceeded, and the cause is a stale selector.

This is the console output of the first run, with the page's own browser console messages removed:

=== Simple Form Demo echoes the message
  FAILED after 1.9s
  AssertionError: Expected values to be strictly equal:
+ actual - expected

+ 'Welcome to TestMu AI'
- 'Welcome to TestMu AI!'
                       ^

  build_id=106552577 test_id=DA-WIN-17458-1790585796090483453DIY session_id=DA-WIN-17458-1790585796090483453DIY

The Automation API returned this evidence for both sessions, and it is what any analysis of them has to work with:

• Command log - Every Playwright call with its duration. For the second test, the failing entry is a Click on #submit-button that ran for 10,016 ms and ended in a TimeoutError.
• Network log - 76 captured requests for the first session, including the 200 response for the Simple Form Demo page, because the session ran with the network capability on.
• Console log - The session API answered "console-cdp logs not available on cloud yet" for these Playwright sessions, so the command and network logs carry the evidence.
• Video and screenshots - Recorded for both sessions and linked from each test in the Automation dashboard.

Before any RCA runs, the Insights API already holds a record for each test. This is the insights object GET /tests returned for the click-timeout test:

{
  "insights": {
    "smart_tags": {
      "is_always_failing": false,
      "is_new_failure": false,
      "is_flaky": false,
      "is_performance_anomaly": false
    },
    "flakiness": { "is_flaky": false, "flake_rate": 0, "compared_test_ids": [] },
    "failure_category": ""
  }
}

Every Smart Tag is false because neither test name had any history, and the record has no rca field, which only appears once an analysis has run. GET /rca/status for the two tests reported both as pending. Triggering the analysis with POST /rca/generate on the test account returned HTTP 402 with this body:

{
  "data": {
    "total_tests": 2,
    "tests_to_trigger": 2,
    "credits_required": 20,
    "credits_available": -3.8954
  },
  "message": "Insufficient credits to generate RCA. Please add credits to your account to access credit-based features.",
  "status": "error"
}

That is the credit gate behaving as documented: the request priced the two tests at 20 credits, the balance could not cover it, and neither test was sent for analysis. On an account with credits, the same call sends both tests to the analyzer and GET /rca/status moves them from pending to completed.

A planted pair like this is a cheap way to check RCA against your own suite before you trust it. Both causes live in the test code, so a correct analysis points at the expected string and at the selector. When it points somewhere else, record the real cause with Suggest Improvements.

How to Run RCA Automatically on the Failures That Matter

Manual RCA waits for someone to click. Automatic AI RCA runs continuously on every failure that matches your rules, with no button press. It lives at Organization Settings > Org Product Preferences > Insights > Automatic AI RCA, applies to everyone in the organization, and needs an Org Admin because non-admin users cannot open Organization Settings.

The AI root cause analysis documentation defines the three analysis scopes: new failures are tests that failed after passing at least 10 consecutive times, and consistent failures are tests that failed in all of their previous 5 runs.

Intelligent Targeting narrows the scope further with regex patterns. Each pattern is added as an Include (+) or Exclude (-) rule on Test Names, Build Names, Test Tags, Build Tags or Project Names, and Job Labels take include rules.

• Include rules - All include rules in the same category must match, and include rules across different categories must all match too.
• Exclude rules - Any single matching exclude rule removes the test from analysis, even if every include rule matched.

The documentation's example limits analysis to production tests from hourly builds in projects whose names start with ecommerce or payment:

Every automatic analysis spends credits, so start narrow. New failures on your release-blocking project is a sensible first scope, because those are the failures someone has to explain before the next deploy. Scheduled HyperExecute Workflows keep HyperExecute features such as RCA, so a nightly suite that runs without a CI server can still be analyzed.

How to Teach the AI Your Failure Categories

Out of the box, the AI classifies failures with its own labels. The Custom RCA Categories and Special Instructions settings on the same Automatic AI RCA page make it classify and reason the way your team does, and both apply to manual RCA as well.

• Custom RCA Categories - Click Manage, then Add Category, and give each category a name, a description and an Active or Inactive status. Only active categories are used for classification. The screenshot above shows three: UI Element Not Found, API Timeout Errors and Database Connection Issues. The documentation recommends starting with 5-10 active categories for your most common failure types.
• Special Instructions - Free text the AI considers during every analysis. The built-in examples cover environment context ("Running on Staging environment with test data"), known issues ("Payment gateway timeouts during high traffic"), analysis preferences, business context such as critical user journeys, and technical constraints such as unstable third-party dependencies.
• RCA Category Trends - The Insights widget aggregates RCA results by category across all executions. Click a category to drill into its failures and track whether it shrinks after a fix ships.

Write categories that name a cause. "Database Connection Timeouts" gives a trend line someone can own, while "Database Issues" collects everything and tells nobody what to fix.

Note: AI RCA, Automatic AI RCA and the RCA API are available on TestMu AI's HyperExecute and App or Web Automation plans, and each analysis uses credits from your organization's balance. Sign up for TestMu AI and generate an RCA on your next failed run.

How to Triage Failures Before You Run RCA

Not every red test deserves an analysis. A test that fails intermittently is a flaky test that needs stabilizing, and a test that has been red all week needs an owner. TestMu AI Insights and its Test Intelligence features answer those questions first, mostly from execution data the platform already records:

The flaky test detection documentation draws the line that matters for RCA: a test that fails with the same error message every time is not flaky. A test that keeps failing is a persistent failure, and that is what the Consistent Failures scope of Automatic AI RCA targets. For fixing the flaky ones, the playbook on how to find, quarantine and fix flaky tests picks up where detection stops.

RCA in Test Manager, KaneAI, App Automation, SmartUI and Your IDE

The same job shows up wherever a failed test does, and each product has its own entry point and scope:

• Test Manager - Open a Test Run, go to the Test Instances tab and click Generate RCA on the failed test. The output shows the root cause, severity and recommended fixes for that test instance in Test Manager.
• KaneAI test runs - In the new KaneAI test run instance view, a failed test shows a banner with Generate RCA and View failed step. It is in Early Access, rolling out in phases, and does not cover Mobile Browser executions.
• Pull requests - The TestMu AI GitHub App runs KaneAI-generated tests on HyperExecute when someone comments "@TestMuAI Validate this PR" (the repository needs a .lambdatest/config.yaml), then posts an RCA summary on the PR, built from screenshots, video, DOM and selector changes, network logs and stack traces, with a recommendation to approve, request changes or investigate.
• Web and App Automation - AI RCA Generation is listed for both products in the organization's AI settings. For a Selenium, Playwright or Appium session outside HyperExecute, trigger RCA by test ID through the API. On the Real Device Plus Automation Cloud plan, Smart Heal for Appium (the smartHeal capability, after one passing baseline run) adds AI analysis and suggestions to failed sessions, along with original versus healed selectors and before and after screenshots.
• Kane CLI - Every Kane CLI run writes an evidence pack: the failed step, per-step console and network logs, an annotated screenshot, and a verdict that separates failed (the product was wrong) from broken (an environment, infrastructure or test fault).
• Visual failures - Smart RCA in SmartUI (Beta) compares the baseline and comparison DOM for a highlighted diff region and shows the DOM path, computed style changes, bounding boxes, attribute and text changes, and layout shifts. The Visual AI Agent (Beta) adds a plain-English summary of each significant change.
• Your IDE - The TestMu AI MCP server gives the agent in Cursor, Claude Code or Copilot a failed test's details plus its command, network and console logs by TestID. The agent does the root-cause reasoning over them; none of the documented tools fetches the stored AI RCA report.
• AI agents that act - For agents that call tools and change state, the rook CLI in Agent Assurance has an --rca option that groups related failures and writes one remedy per cause. It is off by default, costs extra credits, and the product is pre-alpha.

How to Pull RCA Into CI With the API

The Insights public API turns RCA into a pipeline step: trigger analysis for a failed job, poll until it finishes, then post the summary wherever your team reads build results, which for E2E tests in pull requests is the PR itself.

• POST /rca/generate - Finds every failed test in the given job_ids, stage_ids, task_ids or test_ids and sends each one to the analyzer. Tests with an RCA already generated or in progress are skipped.
• GET /rca/status - Returns progress counts (completed, in progress, failed, pending) and the completed results; include_detail=true adds the full analysis to each record.
• GET /rca - Fetches the stored RCA for test, job, task or stage IDs, the same test-level RCA the dashboard displays.
• GET /tests - Returns test records with their Smart Tags, flakiness data, failure category and, once an analysis has run, the RCA category and summary.

TestMu AI's RCA generation API reference caps each ID array at 100 IDs and rejects a scope that resolves to more than 10,000 failed tests with a 413.

# Trigger AI RCA for every failed test in a HyperExecute job, then poll for the results
BASE="https://api.lambdatest.com/insights/api/v3/public"

curl -s -u "$LT_USERNAME:$LT_ACCESS_KEY" -X POST "$BASE/rca/generate" \
  -H "Content-Type: application/json" \
  -d '{"job_ids": ["<JOB_ID>"]}'

curl -s -u "$LT_USERNAME:$LT_ACCESS_KEY" \
  "$BASE/rca/status?job_ids=<JOB_ID>&include_detail=true&limit=20"

The calls take the same username and access key as the rest of the platform, and the run for this guide used exactly that. Each completed record carries an rca_detail object with the fields a CI script needs: root_cause_category, parent_failure_category, failure_summary, the stack traces, an analysis array with the step-by-step failure chain, steps_to_fix entries (issue, module, suggested_fix) and an error_timeline with the source log for each step.

Two response codes belong in that script. A 402 means the organization's credit balance cannot cover the request, and credits are all-or-nothing, so no test is analyzed. A 403 means the AI capability is not enabled for the organization or the caller is a guest user. HyperExecute also exposes a per-task endpoint, GET /v1.0/categorizederrors, that returns the categorized errors for a task with code context and remediation fields.

How to Close the Loop After the RCA

An RCA is a diagnosis, and the failure is not closed until retesting verifies the fix. The HyperExecute rerun documentation spells out the loop: view failed scenarios, identify the fix via AI RCA, apply the fix and deploy, then rerun only the failed scenarios of the job. The right next step depends on what the RCA found:

Auto-heal and muting make a build green without changing the application, so use them only after the RCA has shown the failure is in the test or the environment, and review each heal as the guide to self-healing test automation recommends. The auto-healing documentation itself warns that healing can mask real issues.

Governance, Credits and Data Handling

TestMu AI's defect analysis and prediction documentation lists Insights AI RCA at 15-25 credits per analysis.

• Credits - Every analysis draws on the organization's credit balance, automatic ones included, and the API charges only for newly triggered tests. Only admins can view the balance on the credits management screens, where alerts can warn or block usage below a threshold and budgets can be set for groups and sub-organizations.
• Plans - AI RCA needs a HyperExecute or App/Web Automation subscription, available credits and access to Insights.
• The org-wide switch - The AI capabilities setting is a single Org Admin toggle that turns off every AI feature at once, including new RCA generation in HyperExecute, Web Automation, App Automation and Test Manager, and all of KaneAI. There is no RCA-only switch. AI is on by default, and RCA reports that already exist stay visible when it is off.
• Who configures it - Automatic AI RCA, its targeting rules, categories and instructions are organization settings, so they apply to every user and sit behind Org Admin access.
• Where the model runs - The enterprise readiness documentation describes a private-tenant Azure OpenAI deployment for AI features, and notes that AI-agent features need connectivity to TestMu AI APIs even when test execution runs fully air-gapped. The Insights API also has an EU server.
• What leaves the repository - HyperExecute sends git data for RCA through collectLocalGitData, which is on by default. Set it to false if your policy does not allow that.

AI RCA Limits

• It needs a human to confirm - The RCA panel carries an Experimental label in the documentation screenshots, and the HyperExecute Failure Analysis tab is labelled Beta. Confirm the cause before you merge the fix.
• Only one timing is published - The 20-30 seconds figure is for a HyperExecute job's Failure Analysis tab. Test-level RCA from the Tasks tab, Test Manager, Insights and KaneAI do not state a generation time.
• It sees only what the run captured - Without network or console logs, there is less to correlate. The manual playbook for debugging E2E test failures in CI covers what to capture and how to read it by hand.
• It does not file the bug for you - No documented integration pushes RCA output to Jira or Slack; the GitHub App's pull request comment is the only documented destination. The ticket in your bug tracking tool comes from Mark as Bug in Test Manager or from your own script on the RCA API.
• Coverage differs by product - Generate RCA in KaneAI's new Test Run Instance view is in Early Access, the MCP server's documented tools return test details and logs rather than a stored RCA report, and Flaky Test Detection supports Selenium tests today, with other frameworks listed as upcoming.
• It costs credits every time - In the run above, the API priced two Playwright tests at 20 credits and refused the whole request when the balance fell short.

Get Started

Run your existing suite on HyperExecute, open the first failed test and click Generate RCA. The getting started with HyperExecute guide runs a first test from the portal, the CLI or Gitpod, and once the manual RCA matches what your engineers would have found, turn on Automatic AI RCA for new failures.