Lazarus Pit
A self-healing UX agent that reads this site's Clarity sessions every week, diagnoses friction, and files a GitHub issue with a proposed fix. A human still merges.
Lazarus Pit is a self-healing UX agent for this website. Every Monday it pulls Microsoft Clarity data, compares the numbers against friction thresholds, and files a GitHub issue naming the problem, the likely cause, and a fix worth trying.
The repository is private. Its output is not: every issue it has filed is visible in this site’s issue tracker.
What problem does it solve?
Analytics tools are good at telling you something is wrong and bad at making you do anything about it. Clarity records dead clicks, rage clicks, and quickbacks faithfully, then waits for a human to log in, notice, interpret, and act. On a personal site nobody logs in.
Lazarus Pit removes the logging-in step. The finding arrives where the work already happens, as an issue on the repository that renders the page.
How does Lazarus Pit work?
Four modules run in sequence.
- Fetch.
fetch-clarity.tscalls the Clarity Data Export API for a three-day window and writes the raw response to disk. It tracks its own daily call budget locally and refuses to exceed ten calls a day. - Diagnose.
finding-extractor.tsscores each metric against a warn threshold and a high threshold, then ranks the findings by severity. - Map.
component-mapper.tsconverts each finding into a titled suggestion: what the metric was, what it probably means, and where to look first. - Propose.
pr-generator.tsfiles one GitHub issue per finding on the target repository, labelledlazarus-pit, skipping any finding whose issue is already open.
run.ts chains all four. A GitHub Actions workflow runs the chain every Monday at 14:00 UTC and can also be triggered by hand.
What counts as friction?
| Metric | Warn | High | Reading |
|---|---|---|---|
| Dead clicks | 5% of sessions | 15% | Something looks clickable and is not |
| Rage clicks | 3% | 10% | Element is unresponsive or gives no feedback |
| Quickbacks | 10% | 25% | The link promised something the page did not deliver |
| Script errors | 1% | 5% | JavaScript failing inside real sessions |
| Error clicks | 1% | 5% | A click handler is breaking |
| Scroll depth | below 60% average | below 40% | Content past the fold is not being seen |
Why does it refuse to diagnose small traffic?
The first version filed confident findings off eleven sessions, most of them bots. On that volume a single crawler moves a percentage several points and every threshold becomes noise.
So the agent now subtracts bot sessions from the total and checks the remainder against a floor of twenty human sessions. Below the floor it files one finding and stops: this is a distribution problem, not a friction problem. That single change is the difference between a tool that reports and a tool worth reading.
Why does it not write the fix itself?
It could. Filing a patch is not the hard part.
The hard part is that a site-wide metric cannot tell you which page misbehaved. Clarity’s export API returns numbers for the project, not per URL, so every finding is a site-level hypothesis. Auto-committing against a hypothesis produces confident, wrong diffs that a human then has to reverse. Issues cost a review click and lose nothing.
Escalating to generated pull requests is worth doing once finding quality has earned it. It has not yet.
Why is the repository private?
Nothing in it is secret, but nothing in it is reusable either. Thresholds are tuned to one small site, findings are site-level by necessity, and the fix templates assume this site’s components. Publishing it would ship a tool that mostly teaches people the wrong thresholds for their own traffic.
The parts worth copying are described on this page. If that changes, so will the repository.
Latest meaningful changes
These are product changes, not every repository commit. The list refreshes daily and ignores documentation-only maintenance.
2026-07-13 · Skip findings when human sessions below floor; subtract bot sessions
2026-07-10 · Fix dedup bug: strip live metric value from issue titles · 3 related commits
Also: Add weekly autopilot via GitHub Actions; Initial pipeline: Clarity fetch, finding extraction, GitHub issue filing
Questions people ask
Is Lazarus Pit open source?
No. The repository is private. Its output is public, because every issue it files lands on this website’s public repository under the lazarus-pit label.
Does Lazarus Pit change code by itself?
No. It files a GitHub issue containing the metric, the hypothesis, and a suggested fix. A human reviews, edits, and merges. There is no automatic commit or deploy.
What data does Lazarus Pit read?
Only the Microsoft Clarity Data Export API for this site, which returns site-wide metrics such as dead clicks, rage clicks, quickbacks, scroll depth, and script errors. It does not read session recordings.
Why does it run weekly instead of daily?
Clarity’s export API allows ten calls a day and a three-day lookback. One weekly run stays inside both limits and matches how quickly a small site accumulates enough human sessions to diagnose.
Want to see what it caught?
Its findings are public: browse the open and closed issues it filed against this site. If you are building something similar and want to compare thresholds, book 30 minutes.