How Runtime Recovery Refresh works

Some browser test failures have nothing to do with the behavior you're testing. Consider a page that finishes rendering a moment late, a stalled network request, or a component that normally appears on load but doesn't show up. These issues can fail your test without telling you anything new about your application, forcing you to rerun them just to prove your app is actually working.

With Runtime Recovery Refresh, mabl works through incidental failures in cloud runs at the moment they happen. When a step fails after mabl's usual find and auto-heal attempts, mabl reloads the page and runs the step one more time before reporting a failure. This article explains when Runtime Recovery Refresh runs, what it does, and how to recognize it in test output.

• Auto-heal and Runtime Recovery Refresh
• Reloading the page and retrying the step
• Reviewing recovered steps in test output
• Supported step types
• Local runs

Auto-heal and Runtime Recovery Refresh

mabl uses more than one strategy to keep browser tests passing when something other than the behavior you're testing changes:

• Auto-heal operates at the element level. When an element's attributes change, such as a button's label or CSS class, auto-heal uses the element history to find the next best match.
• Runtime Recovery Refresh operates at the page level after auto-heal. If a step still fails after mabl has waited for the element and attempted an auto-heal, mabl reloads the page and retries the step.

Runtime Recovery Refresh is one of our planned follow-ups to agentic runtime recovery, which we retired in August 2026. Instead of an agent analyzing each failure and choosing a corrective action, there is one predictable recovery, a page reload, and the test output shows you when mabl used it. Unlike its predecessor, Runtime Recovery Refresh does not interact with LLMs.

Reloading the page and retrying the step

When a browser test runs in the mabl cloud on an account with Runtime Recovery Refresh enabled, the following happens each time a supported step fails:

1. The step fails after the usual wait, find, and auto-heal attempts. mabl records the reason, such as an element that was not found or an assertion that did not match.
2. mabl reloads the current page and waits for it to finish loading.
3. mabl runs the same step one more time against the freshly loaded page.
   • If the step passes, mabl marks the step as recovered and the test continues from the next step.
   • If the step fails again, mabl marks the step as failed with the result of the second attempt. The run proceeds as it would for any other failure.

Runtime Recovery Refresh retries each step once. If the second attempt also fails, mabl does not reload again for that step. Each reload adds a page load and a second attempt to the step's duration, so a test whose steps keep failing takes longer to fail than it would without Runtime Recovery Refresh.

Reviewing recovered steps in test output

Runtime Recovery Refresh shows up at the step level in browser test output.

• The step's log includes a line such as Step failed (Element not found); refreshing the page and retrying once. before the second attempt.
• A step that passed on the second attempt shows a Recovered with Runtime Recovery Refresh badge with a refresh icon under its status.

A step that failed on both attempts shows the failure from the second attempt. Its log still includes the reload line, so you can tell that mabl tried a reload before reporting the failure.

Review recovered steps the same way you review auto-heals, to confirm the test is still checking what you intended:

• If the step recovered because the page rendered late or a request stalled, you don't need to change anything. If the same step recovers often, consider adding an assertion or a wait until step before it so the test waits for the page to be ready.
• If the step depended on state from earlier steps on the same page, compare the screenshots from before and after the reload to confirm the recovered step and the steps that follow it acted on what you expected.
• If a step passed after a reload but should not have, share the run with your customer success manager. Runtime Recovery Refresh is new, and examples like these shape how it develops.

Supported step types

Runtime Recovery Refresh retries steps that act on the page or check it:

• Element interactions such as clicks, hovers, enter text, select, and set file input
• Page and element assertions, including visual assertions
• Wait until steps
• Variables created from element properties

Steps that are not retried

A reload cannot help some steps, or would change what the step means, so mabl reports those failures immediately:

• Navigation steps: visit URL, go back, go forward, and reload
• Cookie and viewport steps
• MFA code entry, since reloading a challenge page can invalidate the code
• JavaScript snippet steps and JavaScript variable steps
• Await tab, switch context, file upload wait, and release steps
• Email, download, accessibility, and API steps
• IF and ELSE IF condition steps, and steps set to fail at the end of the run
• Steps that run inside an iframe
• Steps in teardown flows and in performance tests

Local runs

Runtime Recovery Refresh applies to browser tests that run in the mabl cloud. Local runs triggered from the mabl CLI and the mabl Desktop App report the original failure without reloading the page.