It tells you what broke — and why.
When a test fails, Cairn reads the network layer, finds the call that failed, and files the bug report an engineer would write after a day of debugging — while keeping flaky noise off your tracker.
Every failure, read and routed.
Cairn reads each failure, decides what it actually is, and routes it — a root-caused GitHub issue for real bugs, nothing on your tracker for its own flakes.
Cairn reads the network + console + exit signals to decide what this failure actually is.
app/api/billing/route.tsA red X isn't a bug report.
When a test goes red, you've learned almost nothing. A failing assertion says something is wrong, somewhere — but not what broke, why, or where to look. Triaging it means opening the trace, reading the network log, and reconstructing the failure by hand.
Worse, most of what turns a suite red isn't even your bug. Flaky selectors, a momentary timeout, the test runner's own browser crashing — they all show up as the same red X, and they all land in your tracker as noise someone has to triage and close.
Cairn does the triage for you. It reads the failure the way a senior engineer would, writes the report you'd actually want, and only files the failures that are genuinely yours.
From a failure to a fixable issue.
Cairn turns raw run signals into a diagnosis — and decides whether it even belongs on your GitHub.
Reads the network layer
Cairn inspects the API traffic captured during the run, finds the request that failed — a non-2xx, or one that was sent and never returned — and treats that as the root cause, not the assertion that tripped downstream.
Writes the report you'd want
It drafts a product-level issue: what broke, the likely cause, the page and route involved, the app files to check, and a link to replay the run. No stack-trace dump, no Playwright jargon.
Classifies before it files
Every failure is labeled — bug, infra, test-bug, or timeout. Only real product bugs and genuine server problems reach your GitHub; Cairn's own flakes and runner crashes stay in the dashboard.
Leaves a replayable trail
Every issue links back to the exact run — the video and the full Playwright trace — so anyone can watch the moment it broke and confirm the diagnosis for themselves.
A senior engineer's triage, on every failure.
The value isn't an alert — it's the judgement about what broke and whether it's worth your attention.
Diagnosis from real traffic
Cairn leads with the failing API call and, when a response shape changed, names the exact field — so you fix the cause, not the symptom.
Noise stays off your tracker
Flaky tests, timeouts, browser crashes, and resource exhaustion are recognized as Cairn-side and kept off GitHub. When the signal is unclear, it doesn't file.
Replayable, fixable evidence
Every claim is backed by the run's video and trace, and points only at app files you can actually fix — never test files or sandbox paths.
And once a real bug is filed, Cairn can take the next step itself — drafting a fix and opening a pull request — so the issue arrives with a proposed change, not just a description.
Frequently asked questions
A product-level title, what broke, the likely cause, the likely page or route, the app files to check, and a link to replay the run. It reads like the report a senior engineer would write after debugging — not a raw Playwright stack trace.
It reads the network traffic captured during the run, finds the request that failed — a non-2xx response, or one that was sent and never returned — and leads the diagnosis with that call rather than the test assertion that happened to trip.
No. Cairn classifies every failure as a bug, infra, test-bug, or timeout, and only files real product bugs and genuine server/infra problems to GitHub. Flaky tests, Cairn's own runner crashes, and resource exhaustion stay in the dashboard and never reach your repo.
A bug is a real defect in your application. A test-bug is a problem with the test itself or with Cairn's runner — a stale selector, a browser crash, or a sandbox that ran out of resources. Only bugs reach your GitHub; test-bugs are kept off it by design.
It maps the failing API URL to its route handler and pulls the components the flow touched — and it deliberately excludes test files and sandbox paths, so the report points only at code you can actually fix.
Yes. Cairn fingerprints the API responses your flows touch, and when a failure lines up with a changed response shape it names the exact field that changed — type changes, removed fields — as the likely cause.
Every issue links back to the run in Cairn — the full video and the Playwright trace — so you can watch the exact moment it broke, with the network and DOM state at that point.
When the signal is ambiguous, Cairn errs toward not filing on your repo. It would rather keep an unclear failure in the dashboard than open a noisy ticket your team has to triage and close.
Explore more of Cairn
Put your tests on autopilot.
Connect a repo and watch Cairn map your flows, write the tests, and run them on every PR — in minutes.