Self-healing & auto-issues

Upliftr is AI debugging agents that debug your app, read-only by design: they investigate and diagnose, they never mutate your code, data, or infrastructure. Two things make them more than "agents that click buttons": they heal when the UI changes, and they file root-caused issues, correlated to your backend, when something is genuinely broken.

Self-healing

A traditional test fails the moment its locator goes stale. Upliftr doesn't carry stale locators at all, there's nothing to go stale. Every step is re-grounded against the live DOM on every run.

A step like do: "Click 'Create account'" describes intent. So when a redesign moves that button, renames its class, or wraps it in a new component, the agent simply finds it again:

• Read the DOM. Before acting, Claude reads the page's title, URL, visible text, and a numbered list of interactive elements (read_dom). It then acts on an element by its reference (click_element, set_field), resolving the live selector at that instant.
• Adjudicate against what's actually rendered. When an assertion has no deterministic check, the model adjudicates against the page's visible text and a screenshot, so it judges what a user would see, not a brittle locator.

The result: cosmetic and structural UI churn that would turn a conventional suite red just keeps passing. You only get a failure when the behavior is actually wrong.

See Self-heal & root-cause for the mechanics inside a run.

Auto-filed, root-caused issues

When an assertion genuinely fails, the agents don't just paint a step red. They do the triage work:

1. Captures the UI failure, the failing assertion, expected vs. observed, and the network errors recorded during the case (including any trace_id).
2. Correlates to the backend. If the failing request carries a trace_id and you've connected a server-log backend (Loki, Datadog, Elastic, a custom endpoint, or a file), an agent reads the matching log lines (read-only) and asks Claude for the backend error, suspected cause, and a suggested fix.
3. Builds a deduplicated issue. Every failure carries a stable fingerprint, tw:<suite_id>:<case_id>:<assertion_id>:<failure_class>.
4. Files it where you want. To the built-in "File to Upliftr" tracker, and/or to GitHub, GitLab, or Jira, whatever you configure.
5. Never duplicates. A re-run of the same failure comments on the existing issue ("↻ Reproduced again") instead of opening a fresh one. Your tracker stays clean.

This is the difference between a CI run that says "3 tests failed" and a workflow that hands you three well-described, deduped tickets, each pointing at the actual backend problem and a suggested fix.

Configuration, destinations, and the dedup fingerprint are covered in Filing issues and Connecting server logs.

Put together

A nightly run against staging will:

• Pass through harmless UI changes by self-healing.
• Fail loudly and usefully when behavior regresses.
• Hand you a triaged ticket, deduped against prior runs, and (where logs are wired up) carrying the backend error that caused the symptom.

Ready to try it? Head to Getting Started.