What is Upliftr?

Upliftr is AI debugging agents that work across your flow (the browser), your servers (logs and backend), and your machines. You chat with them the way you'd brief a teammate, "the avatar doesn't save," "checkout charges the wrong currency," or "why can't the app reach the payments service," and they drive a real browser (Claude as the brain, Playwright as the hands, on any OS) to reproduce the problem. When something breaks they don't stop at "the UI failed", they trace the failure across the UI, the API, and the exact backend log line that caused it, then file a deduped, root-caused issue with the fix. They are read-only by design: they diagnose, they never mutate your code, data, or infrastructure. Anything they confirm they keep as a plain-English check that re-runs in CI, and they self-heal when the UI changes.

You can chat step by step, or fire one autonomously: give it a symptom, or just "find what's broken", and it investigates on its own, searching logs, probing services, following the failure across layers, until it reports the root cause. Drop it on any environment with read access and it works without a recipe.

In one sentence:

You ship it. The agents debug it. Describe the bug in plain English, they reproduce it in a real browser and hand back the exact backend cause and fix.

What makes it different

Most browser tools answer one question: did the UI break? Upliftr is built to answer the one that's actually hard:

• Why did it break, not just "the assertion failed," but the backend error behind it.
• Where in the backend, a UI failure carrying a trace_id is correlated to your server logs and turned into a concrete diagnosis.
• What's the fix, Claude synthesizes a suspected cause and a suggested fix, then files it as a deduped ticket.

That seam, UI failure → correlated server log → written-up ticket, is the part of the stack that browser automation hasn't commoditized. See Why now for the market reasoning, and Self-heal & root-cause for how it works mechanically.

How a run flows

plain-English YAML suite
        │
        ▼
  Claude reads the live DOM ──► decides actions ──► Playwright drives a real browser
        │                                                   │
        │                                       network errors + trace_id captured
        ▼                                                   │
  assertions adjudicated (deterministic where possible)     ▼
        │                                       failure → server-log correlation
        ▼                                                   │
  report.json · junit.xml · report.html                     ▼
        │                                       Claude: backend error + cause + fix
        ▼                                                   │
  deduped issue filed ◄───────────────────────────────────┘
   (built-in · GitHub · GitLab · Jira)

The core ideas

• Plain-English suites. A case is a list of steps (do:) and expectations. No selectors, no page objects. The LLM grounds each step against the live page at run time. See Writing Tests.
• Claude is the brain, Playwright is the hands. The model reads the DOM and chooses actions (click, fill, select, navigate, create and upload files); Playwright executes them in a real browser on Windows, macOS, or Linux. See Architecture.
• Sequenced, stateful cases. Cases run in order and share state. A suite-level fixtures: block generates a unique user once; later cases reuse the same one. capture shares a produced value forward; depends_on skips a case if its prerequisite didn't pass.
• Deterministic where it counts. Add a check and an assertion is verified with no model call. Omit it and the model adjudicates a forced pass/fail. See Runs & assertions.
• Self-healing. There are no stored locators to go stale, every run re-reads the live DOM, so a moved button or renamed label re-grounds instead of failing.
• Auto-filed, deduped, root-caused issues. A verified failure becomes an issue with a stable fingerprint, filed to your tracker; re-runs comment instead of duplicating. See Filing issues.

How you reach it

Surface	What it is
Dashboard	Vite + React UI: author suites, run them, watch live, triage the issues board, configure integrations.
REST API	FastAPI under /api/v1: suites, runs, issues, settings, generate, analyze, analytics, suites/{name}/export, health. See the API reference.
/analyze — embeddable engine	One call → root-caused bugs. The OEM entrypoint another platform embeds (+ Python SDK, white-label). See Embedding Upliftr.
MCP server	upliftr_root_cause, upliftr_test, upliftr_run_suite, upliftr_check — registers in Cursor & Claude Code, or serves remote agentic platforms over HTTP. See IDE & MCP.
CLI	upliftr run and upliftr test-url, designed as a CI gate. See the CLI reference.
GitHub Action	action.yml, run suites and gate PRs. See CI.
GitLab CI	a job / CI component, run suites and gate MRs. See CI.

What it is not (yet)

Upliftr leads with functional + backend-root-cause strengths, it finds broken flows and root-causes them. It is not a security scanner: it surfaces user-facing symptoms and root-causes them, but pair it with a dedicated scanner for deep secret/authz audits. Mobile (simulators) is on the roadmap; web is the focus today.

Next: Why now · Getting Started