Not all test failures are created equally. Sometimes tests fail for incidental reasons, such as a button that wasn’t responsive on the first click, or a newly created record landing on the second page of a paginated list. These types of failures have nothing to do with what you’re actually testing, and they distract you from focusing on more critical work.
Agentic runtime recovery reduces avoidable failures in browser tests by intelligently recovering from issues that are outside the test’s critical path. When a step fails during execution, mabl activates an agent to analyze the failure and attempt corrective actions before the test is marked as failed.
Early access
Runtime recovery is currently available in early access. To turn on runtime recovery, workspace owners should enable the following settings on the Labs page: Settings > Labs
- Use preview AI models in mabl agents - the data processing location of preview models is not guaranteed to be US-based.
- Runtime recovery - this setting is only available in workspaces that have enabled preview models for mabl agents.
If you have any feedback regarding the experience, please share it with your mabl customer success manager (CSM).
Auto-heal vs. runtime recovery
mabl uses multiple strategies to keep tests running when things change.
- Auto-heal operates at the element level. When an element’s attributes change, such as a target button’s CSS class, auto-heal uses attribute history and AI to find the next best match.
- Runtime recovery operates after auto-heal. If auto-heal can’t resolve a step failure, the agent investigates issues that go beyond element attributes, such as unexpected page states, blocked UI, or missing content.
How runtime recovery works
When a step fails and auto-heal doesn’t resolve the issue, the agent activates and performs the following actions:
1. Analyze the failure
When deciding whether a failure is worth recovering, the agent uses the test’s purpose as context and examines the current failure alongside context from previous passing and failing cloud runs of the same test. Importantly, if the agent recognizes the failure as core to what the test is validating, runtime recovery does not activate and the step fails.
2. Attempt corrective actions
If the issue is caused by something outside of the test’s intent, the agent takes actions to resolve the issue, such as:
- Dismissing an unexpected modal or popup
- Clearing a stale search filter from a previous session
- Navigating to the correct page in a paginated list
- Retrying an unresponsive button
- Refreshing the page
3. Next steps
If recovery is successful, the agent returns control to the execution engine and the test continues. If recovery is not successful, the test fails with a detailed explanation of what failed, what the agent tried, and the outcome.
When runtime recovery activates, the test output includes an explanation of what happened:
- What step failed and why
- What corrective actions the agent attempted
- Whether recovery was successful
Recovery modes
By default, runtime recovery marks the step as failed, continues execution, and fails the test at the end.
Supported and unsupported step types
Runtime recovery is supported for browser tests that execute in the mabl cloud. While supported for most types of test steps, runtime recovery does not activate for the following step types:
- API requests
- Database queries
- Echo steps
- Email steps
- Download assertions