neverflake Sign in

Scheduled browser regression checks

Green that is earned.

neverflake runs a real browser against your site on a schedule, fingerprints what it sees, and reports exactly what it observed. Nothing more. A pass means the checks passed — not that your site is perfect. A failure names what broke, when, and against what baseline.

Open the console Passwordless — a sign-in code by email.
run #241 · example-shop.test 2026-08-01 04:47 UTC · 1327ms

✕ Failed — 2 of 4 checks

  • HTTP status is 200
  • Page has a non-empty title
  • At most 0 console errors — found 2, first: TypeError: cart.checkout is undefined
  • Selector #checkout-button exists — not found

Drift against baseline v3 — approved by a human, 12 runs ago:

1 renamed 1 removed

#submit-btn → #btn-submit

Illustration — how a failing run reads. Not customer data.

What runs

A real browser

Every run drives real Chromium against your URL — the same engine your users bring, not an HTTP probe pretending to be one.

On a schedule, or from your CI

Manual, daily or hourly. A missed run fires once on recovery, not a stampede. Or trigger a run from your pipeline with an API key and read the result back.

Your checks, plus a fingerprint

Define your own checks — status, title, selectors, console errors, load budget — or run four sensible defaults. Every run also fingerprints each visible interactive element.

What it reports

Drift, against a baseline you approved

The fingerprint is compared against a pinned baseline that only advances when a human approves it — never a rolling average. The same change is reported until you accept it, so drift you did not read on Tuesday is still visible on Wednesday.

Identity is tag, role and accessible name — not the selector. A renamed button reads as a rename, with the old and new locator side by side, not as one element vanishing and a stranger appearing.

Failures reach you where you work

Every failed run emails a report link that works without signing in — what broke, which check caught it, and the evidence, with nothing softened. Add Slack or a webhook to get it in your team's channel too.

Drift is reported as change, not failure: a deploy that renames a button is the deploy working. When you approve the new baseline, any selector checks pointing at the moved element update to follow it — the locators heal themselves. It never turns a passing run red.

How it is built

One microVM per run

Each run gets a fresh Firecracker microVM with its own kernel, restored from a certified snapshot in milliseconds and destroyed when the run ends.

Nothing shared

Your pages never share a browser, a cache or a cookie jar with anyone else's. Every run starts from the same audited memory image.

Fails closed

If the sandbox cannot start, the run errors and says so. There is no fallback to a shared browser — an error is honest, a quiet downgrade is not.

What it does not do

It does not abolish flakiness

The name is the goal, not a claim. We detect drift and report what each run observed; flaky infrastructure still exists.

It does not certify your site works

A pass means the checks passed on that run, at that time, from our vantage point. That is all a monitoring tool can honestly say.

It does not test signed-in flows yet

Public pages only. Checks that carry your credentials need guarantees we are not ready to promise.

It does not invent numbers

No fabricated counts, no borrowed logos, no praise we did not receive. This page has none because we are new, and saying otherwise would be lying to you on first contact.

Plans

Free to start: one site, manual runs, full drift detection. Paid plans with scheduled runs exist but their pricing is not final — the console states which numbers are still draft.

Start checking a URL No card. No sales call.