sdods run -p checkout-web -e staging -l ui -b chromium -t @regressionSame suite, same machine, same worker count. Before healing it was about six minutes, now it is nineteen and change. Nothing failed either way, which is why I assumed healing was free when the locators work.
Where is the time going?
Accepted answer
Healing is free when the locators work. Nothing runs until the primary locator times out, and then the cost is bounded: primaryTimeoutMs at 3000, then every candidate probed in parallel inside probeTimeoutMs at 1500. Worst case is about four and a half seconds for one locator, not the thirty-plus you would get from a chain of fallbacks tried one after another.
Thirteen minutes of extra wall clock means something in the region of a hundred and fifty locators are timing out and being rescued. Your suite is not slower — it is finally telling you how broken it already was.
sdods heal report --lastRead the occurrences column. My guess is that a handful of descriptions account for most of it.
Worth adding the pipeline angle. The same run on a loaded agent will hit primaryTimeoutMs on locators that are merely slow rather than wrong, and then heal to the same element it was already waiting for. Those appear in the report as heals whose winning selector is effectively the primary.
They are noise, and the fix is not to lower the timeout. It is to work out why the page takes more than three seconds to show that element.
We had exactly this after a design system upgrade. The report showed two descriptions at forty-odd occurrences each — a nav item and a submit button that had both moved to new components. Fixed the two page objects, run time went back to normal. Total damage: one afternoon.
Have a different question? Ask it.