Self-healing Playwright automation: repair one step, not the run

Blog·By Rohit Kashyap·Published 18 October 2026

I build Dejo, which does a version of what this post describes, so weigh my opinions with that in mind. The facts about Playwright come from its own docs.

"Self-healing" gets used for two different things, and it helps to pull them apart before choosing a tool.

The first kind fixes the test file. Something fails, an AI looks at the page, writes a new locator into your code, and runs the test again. The second kind fixes the step at run time. Each step already knows several ways to find its button, so when one stops working it quietly uses another, and only asks for help when all of them are gone.

The first kind: Playwright's healer

Playwright ships three Test Agents: a planner, a generator and a healer. According to its docs, when a test fails the healer agent:

1. replays the failing steps,
2. inspects the current UI to find equivalent elements or flows,
3. suggests a patch (a locator update, a wait adjustment, a data fix),
4. reruns the test until it passes or until guardrails stop the loop.

The output is "a passing test, or a skipped test if the healer believes that functionality is broken." You set it up with npx playwright init-agents, and it works from Claude Code, Codex, VS Code and OpenCode.

This is the right tool if what you own is a Playwright test suite. The fix lands in your repo as a code change you can review.

The second kind: many ways to find one button

The other approach keeps more than one locator per step from the start. Dejo stores up to nine for every control a route touches: test id, link target, label, role, placeholder, alt text, title, visible text and CSS. They're ranked by which ones have actually worked on past runs, so the best one is tried first.

Most site changes only break one or two of those. A designer renames a CSS class; the label and the link target still work, and the step lands as before. Nobody is asked anything and no model is called.

Not every element gives you nine good options, though. Here's a real step from my own Dejo memory, a route that reads the open-issue count on a GitHub repo:

+ step 2  the exact open issue count for microsoft/playwright
          [css:div > div:nth-of-type(1) > ul > li:nth-of-type(1) > a]

That number sits in a plain element with no test id and no label, so the locator that worked is a CSS path, and CSS paths are the first thing a redesign breaks. This is exactly the case the next part is for.

When every locator fails

When none of the stored ways can find the control, Dejo doesn't guess. It stops at that one step and returns a repair request: which step broke, what it was for in plain words ("read the open issue count"), and the controls that are on the page now, each with a ref.

Your agent picks the right one and calls dejo_repair with that ref. Dejo then looks up the chosen element and stores every durable way of finding it, the same as when the step was first learned. Its tool docs are blunt about why it asks for a ref instead of a CSS selector: "A repair that stores one CSS path leaves the step more fragile than when it started, which is backwards."

Only that step changes. Steps one, three and four of the route aren't touched, and the next run goes back to costing nothing.

The part people skip: proving the step worked

Healing that never checks its own work is just guessing with extra steps. If a step clicks "something that looks like the Save button" and moves on, a wrong pick passes silently, and you find out a week later.

So every step Dejo saves carries a check that proves it landed: the address changed, the file downloaded, the field holds what was typed, the row count is what it should be. If a click does nothing, the check fails, and the run stops and says so instead of carrying on with a wrong answer. Playwright's healer has its own safety valve for this: it will mark a test as skipped when it thinks the feature is broken, so a bug doesn't get "healed" into a pass.

When the whole site is rebuilt

Repairing step by step makes sense for a moved button. It makes no sense when most of the site is new. If more than half of a route's steps break, Dejo treats the site as rebuilt: it drops the route, keeps the facts it learned about the site (it needs a sign-in, it texts a code to your phone), and the agent learns the task again. That second learning starts from those facts, so it's cheaper than the first visit.

Which one do you want?

The two come from different places. The healer edits code you'll review. Dejo keeps memory your agent replays. If your problem is "my agent re-learns the same dashboard every morning and breaks when it changes", that's the second one. There's more on the cost side in why your agent re-reads every website.

FAQ