Analytics that read your code— and fix what they find.

xlens maps every click to component → file:line, watches real sessions on your own server, and opens pull requests for the engineering, UX and UI problems it finds. Then it checks that the fix actually worked.

★ Star on GitHub

~4 KBbrowser SDK, gzipped
file:linefor every click
0cloud dependencies
1 PRper issue, verified

shop — src/pages/Checkout.tsx⎇ main

29  return (30    <section className="checkout">31      <h2>Checkout</h2>32      <form onSubmit={submit}>33        <label>34          Postcode35          <input name="postcode" required pattern="[0-9]{6}"+          <input name="postcode" required pattern="[0-9]{3} ?[0-9]{3}"+            inputMode="numeric"36            placeholder="e.g. 560 001" autoComplete="postal-code" />37        </label>38        <button className="btn primary" type="submit">

~/shop ❯ npx xlens issues --kind validation-loop
  UX-0003  high     ux          fixable   Postcode rejected 3.1× per session [pr-open .../pull/128]
            fix verified: 41% → 3% of sessions in build c19a0e2 (n=812, p<0.001)
~/shop ❯ 

01 — the loop

From a click in production to a merged fix, in one pipeline.

Most analytics tools record behaviour and work backwards to the code. xlens starts from the code, so every issue already knows its file, and so does the fix.

A tiny SDK records what people do, never what they type.

Clicks, navigation, form validity, API timing, errors and vitals. Field values never leave the browser, query strings are stripped, and routes are normalised.

src/main.tsxts

import { init } from '@xlens/sdk';

init({
  endpoint: 'https://ux.internal.example.com/v1/e',
  app: 'shop',
});

Every interactive element knows where it lives in your code.

The build plugin stamps each element with a stable id tied to component → file:line, and the scanner maps every fetch to its call site. Works with Vite, webpack, Rollup, esbuild, Rspack and Next.js (Turbopack).

dist/assets/Cart.js → app-model.jsonjson

// <button data-xlens-id="1k3x9qa">Apply</button>
{
  "uxId": "1k3x9qa",
  "component": "Cart",
  "file": "src/pages/Cart.tsx",
  "line": 45,
  "tag": "button",
  "label": "Apply",
  "screens": ["/cart"]
}

Your own server turns sessions into ranked issues.

Node and SQLite, no cloud. Issues are ranked by the share of a screen’s traffic they hit and what they cost in conversion. A newer build that is significantly worse gets flagged as a regression.

/var/lib/xlens/issues.logjson

{
  "event": "new",
  "id": "UX-0005",
  "kind": "dead-click",
  "severity": "high",
  "title": "\"Apply\" button on Cart does nothing when clicked",
  "detail": { "affected": 99, "rate": 0.345, "screen": "/cart" }
}

It writes the fix, runs your checks, and opens a PR.

Each fix runs in a git worktree with repo-scoped tools. Edits to manifests, lockfiles, CI or .env are rejected. Only fixes that pass typecheck, build and test are committed, one commit per issue, and humans merge.

src/pages/Checkout.tsxdiff

<label>
     Postcode
-    <input name="postcode" required pattern="[0-9]{6}"
+    <input name="postcode" required pattern="[0-9]{3} ?[0-9]{3}"
+      inputMode="numeric"
       placeholder="e.g. 560 001" autoComplete="postal-code" />
   </label>

Passing checks prove it builds. xlens proves it worked.

After a fix ships, the server waits for a later build with enough traffic on that screen and compares the issue’s rate before and after. The fix is marked verified, not-improved or pending.

GET /v1/apps/shop/issues/UX-0003json

"fix": {
  "status": "pr-open",
  "pr": "https://github.com/acme/shop/pull/128",
  "outcome": "verified",
  "impact": {
    "build": "c19a0e2",
    "before": 0.41, "after": 0.03,
    "sessions": 812, "significant": true
  }
}

02 — what it finds

22 issue types across engineering, UX, UI and product.

Every issue is ranked by reach and cost, keeps a stable id across runs, and is marked resolved when it stops appearing. Open a file to see how it's detected.

ISSUES

▾ engineering/

▾ ux/

▾ ui/

▾ product/

issues/engineering/http-error.md

kindhttp-error

categoryengineering

detectedAn endpoint's error rate is ≥5%, mapped to the fetch call site in your code.

fixable✓ auto-fix → PR

exampleGET /api/stock 503 · 15.2% of calls · Cart.tsx:28

// Failures and slowness, pinned to the call site that caused them.

issues/engineering/slow-api.md

kindslow-api

categoryengineering

detectedp75 latency ≥ 1s per endpoint, mapped to its call site.

fixable✓ auto-fix → PR

exampleGET /api/recommendations p75 1.84s · ProductPage.tsx:19

// Failures and slowness, pinned to the call site that caused them.

issues/engineering/js-error.md

kindjs-error

categoryengineering

detectedUncaught errors, attributed to the click that caused them.

fixable✓ auto-fix → PR

exampleTypeError: Cannot read 'qty' · after click on Remove

// Failures and slowness, pinned to the call site that caused them.

issues/engineering/error-click.md

kinderror-click

categoryengineering

detectedA click that is followed by an uncaught error, pinned to the element.

fixable✓ auto-fix → PR

exampleRemove (cart line) → TypeError · Cart.tsx:31

// Failures and slowness, pinned to the call site that caused them.

issues/engineering/resource-error.md

kindresource-error

categoryengineering

detectedImages, scripts or stylesheets that fail to load.

fixable✓ auto-fix → PR

example/img/hero-autumn.jpg 404 · Home.tsx:12

// Failures and slowness, pinned to the call site that caused them.

issues/engineering/slow-page.md

kindslow-page

categoryengineering

detectedp75 LCP per screen.

fixable✓ auto-fix → PR

example/ LCP p75 3.4s

// Failures and slowness, pinned to the call site that caused them.

issues/engineering/main-thread-blocking.md

kindmain-thread-blocking

categoryengineering

detectedShare of views where the main thread is blocked for ≥300ms.

fixable✓ auto-fix → PR

example/products · 27% of views blocked

// Failures and slowness, pinned to the call site that caused them.

issues/engineering/slow-interaction.md

kindslow-interaction

categoryengineering

detectedINP per element.

fixable✓ auto-fix → PR

example"In stock only" INP 480ms · Products.tsx:41

// Failures and slowness, pinned to the call site that caused them.

issues/engineering/layout-shift.md

kindlayout-shift

categoryengineering

detectedp75 CLS per screen.

fixable✓ auto-fix → PR

example/products CLS 0.21

// Failures and slowness, pinned to the call site that caused them.

issues/ux/dead-click.md

kinddead-click

categoryux

detectedClicks with no navigation, request, DOM change or error.

fixable✓ auto-fix → PR

exampleApply (coupon) · 34% of cart views · Cart.tsx:45

// Where people struggle, even when nothing throws.

issues/ux/rage-click.md

kindrage-click

categoryux

detectedRepeated clicks in one spot in a short window.

fixable✓ auto-fix → PR

exampleApply (coupon) · 3+ clicks in 1.2s

// Where people struggle, even when nothing throws.

issues/ux/validation-loop.md

kindvalidation-loop

categoryux

detectedThe same field rejected again and again in one session.

fixable✓ auto-fix → PR

examplepostcode rejected 3.1× per session · Checkout.tsx:35

// Where people struggle, even when nothing throws.

issues/ux/form-abandon.md

kindform-abandon

categoryux

detectedForms started and never submitted.

fixable✓ auto-fix → PR

example/checkout · 41% start, never submit

// Where people struggle, even when nothing throws.

issues/ux/u-turn.md

kindu-turn

categoryux

detectedBouncing straight back to the screen you came from.

fixableneeds a decision

example/size-guide → back in < 4s · 62%

// Where people struggle, even when nothing throws.

issues/ui/unseen-cta.md

kindunseen-cta

categoryui

detectedA step on the main flow that's rarely on screen, or much less on mobile.

fixable✓ auto-fix → PR

exampleProceed to checkout · seen by 38% on mobile vs 97% desktop

// Read straight from your source, then weighted by real traffic.

issues/ui/accessibility.md

kindaccessibility

categoryui

detectedImages without alt, clickable <div>s, unlabelled fields, icon-only buttons, <a onClick>.

fixable✓ auto-fix → PR

example<div onClick> zoom · ProductPage.tsx:52

// Read straight from your source, then weighted by real traffic.

issues/ui/contradictory-validation.md

kindcontradictory-validation

categoryui

detectedA placeholder example that fails its own pattern.

fixable✓ auto-fix → PR

exampleplaceholder "560 001" ∉ pattern [0-9]{6}

// Read straight from your source, then weighted by real traffic.

issues/product/flow-dropoff.md

kindflow-dropoff

categoryproduct

detectedFunnel built from the path converting users actually take.

fixableneeds a decision

example/cart → /checkout · −46%

// Decisions for humans, backed by funnels built from what converting users actually do.

issues/product/device-gap.md

kinddevice-gap

categoryproduct

detectedMobile and desktop conversion diverge on a step.

fixableneeds a decision

examplecheckout conversion · mobile 9% vs desktop 31%

// Decisions for humans, backed by funnels built from what converting users actually do.

issues/product/dead-end.md

kinddead-end

categoryproduct

detectedScreens people leave the app from.

fixableneeds a decision

example/size-guide · 28% exits

// Decisions for humans, backed by funnels built from what converting users actually do.

issues/product/unused-feature.md

kindunused-feature

categoryproduct

detectedFeatures people see but never use.

fixableneeds a decision

exampleWishlist button · 0.4% use

// Decisions for humans, backed by funnels built from what converting users actually do.

03 — in your agent

Hand production issues to the agent you already use.

xlens mcp is a stdio MCP server. Your agent gets the issue, the evidence, the timelines and the source with line numbers: the same brief xlens fix uses. It reports the result back to your server.

terminalbash

claude mcp add xlens -e XLENS_TOKEN=… -- npx xlens mcp

.cursor/mcp.jsonjson

{
  "mcpServers": {
    "xlens": { "command": "npx", "args": ["xlens", "mcp"], "env": { "XLENS_TOKEN": "…" } }
  }
}

~/.codex/config.tomltoml

[mcp_servers.xlens]
command = "npx"
args = ["xlens", "mcp"]
env = { XLENS_TOKEN = "…" }

agent session

youfix the worst open xlens issue
toollist_issues(minSeverity: "high", fixable: true)
→ UX-0003 validation-loop · Postcode rejected 3.1× per session
→ UX-0001 dead-click · "Apply" on /cart
toolget_issue("UX-0003")
→ evidence · 41% of checkout sessions · regression in b7d2e41
→ src/pages/Checkout.tsx:35 · pattern="[0-9]{6}"
agentedits Checkout.tsx · runs tests · opens PR #128
toolrecord_fix("UX-0003", "pr-open", pr: "…/pull/128")
→ recorded · will verify on the next build

04 — architecture

Three places, and nothing leaves them that shouldn't.

The server never needs your source code or an internet connection. The machine that fixes never needs your users' data, only the issues. Credentials stay where they already are.

01your users' browsers

@xlens/sdk · ~4 KB

clicks, nav, forms
API timing, errors
vitals, visibility

⊘ never sends input values

02your server (on-prem)

xlens serve

every session → events.db
analysis every 15m
issues.log · report · admin API

⊘ never needs your source

03a dev machine or CI

xlens fix · xlens mcp

worktree → fix → checks
commit → push → gh pr
your git + gh credentials

⊘ never sees users' data

// app model: xlens scan --push after each release, from build plugin → server

05 — safety model

Strict by default. Lint rules you can't turn off.

✔ xlens/no-input-values error

No input values, ever.

The SDK sends field names, lengths and validity, never what was typed. Query strings are stripped and routes normalised. Do-Not-Track and Global Privacy Control are respected.

✔ xlens/labels-from-controls-only error

Text comes from controls only.

Up to 40 characters from buttons, links and form controls. Emails become <email> and runs of digits become <num> before anything is sent. Turn it off with captureText: false.

✔ xlens/evidence-is-untrusted error

Evidence is untrusted.

Labels and errors come from browsers, so the fix engine gets them as data. Its tools can't reach anything outside the repo's editable folders and your configured checks.

✔ xlens/humans-merge error

Humans merge.

xlens only ever opens PRs, with one commit per issue, so a reviewer can drop any of them. Manifests, lockfiles, CI and .env files are off limits.

06 — compare

Not another dashboard. The step after it.

Playwright tests what you expect users to do. Session tools show what they did. xlens finds what they actually hit, traces it to the line, and fixes it. Use it alongside the tools you already have.

Capability	xlens	Playwright	PostHog	FullStory / LogRocket	Sentry	Datadog RUM
Maps findings to component → file:lineOthers map JS errors through source maps, but not clicks, forms or UX issues.	✓	—	—	—	◐	◐
Real-user sessionsPlaywright drives scripted, synthetic browsers.	✓	—	✓	✓	✓	✓
Dead and rage clicks	✓	—	✓	✓	✓	✓
Root cause found in codeFor example, a validation pattern that rejects its own placeholder.	✓	—	—	—	◐	—
Funnels from real paths	✓	—	✓	✓	—	◐
Writes the fix and opens a PRAI fix features elsewhere focus on errors and exceptions.	✓	—	—	—	◐	◐
Verifies the fix on later buildsxlens runs a one-sided z-test on the issue rate in builds after the fix.	✓	—	—	—	◐	—

✓ yes · ◐ partly · — no · Based on public docs as of Nov 2026. Spotted a mistake? Open an issue.

Full comparison →

07 — pricing

One plan. It's free.

package.json

"license": "MIT"

$0/ forever · self-hosted

Every detector: engineering, UX, UI, product
Unlimited apps, sessions and retention
Auto-fix PRs with your own model key or CLI agent
Fix verification on later builds
MCP server for Claude Code, Cursor, Codex
Self-hosted: Node + SQLite, no cloud

Read the docs →

cloud.ts

// TODO: xlens cloud

A hosted server for teams that would rather not run one. Same detectors, same PRs.

Join the waitlist

Is it actually free?

Yes. xlens is MIT licensed and runs on your own infrastructure. The only cost is the model tokens for auto-fixes, billed by your own provider. Plug in a CLI agent instead and that cost is whatever you already pay.

What does it need to run?

Node 22.13+ for the server (it uses node:sqlite, so no native dependencies). React apps with Vite, webpack, Rollup, esbuild, Rspack or Next.js. More frameworks are on the roadmap.

Will there be a paid cloud?

Maybe later, for teams that would rather not run a server. Self-hosted xlens will stay free and complete.

Where does my data go?

Nowhere you don’t control. Sessions stay on your server, source stays on your machines, and fixes go through your own git and gh logins.

08 — git log --blog

From the changelog of our thinking.

All posts →

Ship it. xlens will tell you what broke, and fix it.

zsh — ~/your-app

❯ npm i @xlens/sdk && npm i -D @xlens/plugin @xlens/cli
❯ npx xlens init
Created xlens.config.json
❯

★ Star on GitHub