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
• Choosing a mode for a plan
• 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.

Choosing a mode for a plan

Runtime Recovery Refresh is configured at the plan level in the Advanced section. Every plan starts with the mode off, so nothing about your runs changes until you pick a mode and save the plan.

Choose Refresh, but fail the test at the end while you are still deciding whether to trust a reload on a given plan. mabl works through the rest of the test, so you see every failure in the run rather than only the first one, and the failed result keeps the run in front of you.

Runtime Recovery Refresh reads the mode from the plan the test ran in. A test that runs outside a plan, such as an ad hoc run started from the test list, does not use Runtime Recovery Refresh.

Reloading the page and retrying the step

When a browser test runs in the mabl cloud under a plan with a Runtime Recovery Refresh mode of On or Refresh, but fail the test at the end, 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. Under Refresh, but fail the test at the end, the run still ends as failed.
   • If the step fails again, mabl marks the step as failed with the result of the first attempt and notes the retry's failure in the step log. 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 badge with a refresh icon under its status. Under On, the badge reads Recovered with Runtime Recovery Refresh. Under Refresh, but fail the test at the end, it reads Retry passed with Runtime Recovery Refresh; the plan fails the test at the end.

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

To pick the reloaded steps out of a long run, filter the step list by Runtime Recovery Refresh. The filter matches every step mabl reloaded, whether or not the retry passed. See filtering steps in test output.

Comparing the page before and after the reload

On a step that mabl reloaded, the Screenshots, Network, and DOM tabs each carry an Attempt switch:

• Initial attempt shows what mabl captured when the step first failed: the screenshot and DOM from the original page, and the network requests the step made.
• After refresh shows the reloaded page: the screenshot mabl took once the page finished loading, the DOM as it stood going into the retry, and the network requests the reload itself made. The status summary above the request list belongs to the initial attempt, so it isn't shown for the reload.

Each tab remembers its own setting, so you can read the initial screenshot alongside the requests from the reload. Comparing the two attempts is the quickest way to see what the reload changed, which is what tells you whether the recovered step acted on the page you expected.

Deciding whether to trust a recovered step

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 the initial attempt and after the refresh 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.