Invite-only pilot · 3 weeks

Your coding agent can't tell a flaky test from a broken one.

Claude sees a failing test and a single run to learn from, so it makes the test pass — loosens the assertion, adds a retry, bumps a timeout. With one run to go on, a real regression and a flake look identical. Xping gives it the history and the evidence to tell them apart.

Every dotnet test run gets recorded — local runs that never reach CI included. Pooled across your team, that history becomes a per-test confidence score with the evidence behind it: in the terminal for developers, in the portal for everyone who owns the release.

Apply for the Pilot Start locally, free ↓

$99 flat · up to ~10 users · fully credited toward your first paid month · 6 spots left this cohort

The problem

A test fails. Claude has one data point and a green build to chase. So it edits the test.

Loosened assertion

The test still runs. It just stopped checking the thing that broke.

Retry added

A real, reproducible failure now passes on attempt three.

Timeout bumped

The race condition is still there. It's just harder to hit in CI.

Every one of those is a reasonable move on one data point. Nobody notices until the suite stops meaning anything.

What Xping does

Record, score, answer — on your real test data, with no changes to your tests.

A single run can't tell you whether a test is trustworthy. Enough runs can. Xping captures every one of them, turns them into a per-test confidence score, and answers questions against that history.

Record

Local + Cloud

Every test execution is captured as it happens — including the dotnet test runs on your laptop that never reach CI, which is where most of the evidence has always been thrown away.

Score

Cloud

Every test gets a confidence score and reliability tier from a 6-factor model, plus an Effective Sample Size and an Evidence Level saying how much history stands behind that number. One machine's runs can't produce an honest score — it takes history pooled across machines, branches and CI.

Answer

Local + Cloud

Is this test trustworthy, and is this failure real? Ask from the terminal, read it in the portal, or let your agent ask directly. What comes back is the run history, the failure pattern and the evidence behind the score — not a bare verdict.

How Claude uses it

Your agent asks before it edits.

Before it touches a failing test, Claude asks Xping what that test's history actually says. What comes back is evidence, not a verdict — Claude still decides what to do with it.

Step 01

Claude hits a failing test

Instead of rewriting the assertion on one red run, it asks Xping what this test's history actually looks like.

Step 02

Xping answers with evidence

Confidence 0.22. Failed 34 of 34 canonical runs. ESS 34, evidence High. The same failure signature on six machines and in CI.

Step 03

Claude fixes the code, not the test

A failure that consistent isn't flake. It's your bug — and the test was right to catch it.

It works the other way too. Confidence 0.91 with a single local failure is noise: don't touch the test, run it again. That answer saves the human an afternoon as surely as it saves the agent a bad edit.

One CLI, two sources

One command. Your machine's history, and your whole team's.

xping report is the one command you actually run. It answers from your own repo's history and, once you're signed in, from everything your team, your branches and CI have contributed — both in the same report. A wider pool doesn't change the command, only how certain the answer is.

Local

No account · MIT-licensed

One machine's worth of evidence: every run you've made. Enough to see that a test is inconsistent, or that it's been failing the same way all afternoon. Not enough to say how far you can trust it.

dotnet add package Xping.Sdk.XUnit
dotnet tool install -g Xping.Cli
dotnet test
xping report

What the report gives you

Run-by-run pass/fail history
Inconsistent & newly-failing tests
Consistently-failing tests (real bugs)
Duration & environment capture

Local-first quickstart →

Cloud

Account required · invite-only during the pilot

Every machine's evidence in one pool — your laptop, your teammates', every branch, every CI job. Enough runs to put a number on trust: this test fails 3% of the time and it isn't your change, or it's failed 34 of 34 times and it is.

export XPING_APIKEY="..."      # SDK uploads: every machine + CI
xping login                    # you sign in, in the browser
xping report                   # same command, both sources

Everything local, plus

Per-test confidence score
Root-cause categorisation
History across CI, branches, teammates
GitHub pull-request comments

Apply for the Pilot

What that looks like. The two sources sit side by side in the same report — local tells you what just happened, cloud tells you whether it means anything.

xping report                     source: local + cloud · main · window: 7d

Session  2026-08-25 14:32  ·  248 tests  ·  1m 47s  ·  3 failed, 2 retried
Suite confidence  0.81  ▼ 0.04    Quarantined: 2

NEEDS ATTENTION

  ✗ PaymentTests.Refund_IssuesCredit
      local   failed · InvalidOperationException
      cloud   confidence 0.22  ▼ 0.61   not flaky — consistent failure
              failed 34/34 canonical runs since 2026-08-23 09:14
              ESS 34 · evidence: High
              same failure signature across 6 machines and CI

In the portal

The release call isn't made in a terminal.

The people who make that call — QA, leads, product — open app.xping.io and see the same history and the same scores the CLI gives developers. Nothing to install.

The Xping Cloud overview screen: counts for tests needing attention and flaky tests, a ranked list of unreliable tests with confidence scores and reliability tiers, and a recent sessions feed. — The first screen you land on. Six tests need attention, each with a confidence score, a reliability tier and how much evidence stands behind it — ranked, so you know what to look at before anyone asks.

Can we ship this?

One number for the whole suite, and which way it's moving. Not a pass rate — that stays green while the tests quietly stop checking anything.

What's costing us?

The flaky tests ranked by how much time they're burning, with the cause written out in plain language rather than left as a stack trace.

Is this failure real?

Test insights posted straight onto your GitHub pull requests, so a reviewer gets the answer where the review already happens.

The 3-week pilot plan

See what your suite is actually doing — in three weeks.

You're one of a small number of invited teams piloting Xping. Here's exactly what the next three weeks look like.

~2–3 hours of your time total.

Week 1

Onboard & baseline

Install the SDK and the CLI, wire into CI, first sessions flowing. Pilot kickoff call. Goal: history pooling from every machine by end of week.

Week 2

Insight & action

Enough runs for meaningful scores. Review flaky tests, act on one or two, point your agent at the report. Mid-pilot check-in.

Week 3

Evaluate & convert

Review what measurably changed against your success metrics. Pilot close-out call and decision on a plan.

What's included

Everything you need to trust your suite.

Xping is an early MVP — the core below is solid and fully working; a few areas are intentionally limited for now.

Scoring

Per-test confidence & reliability tiers

Effective Sample Size and an Evidence Level on every test, not just a pass/fail.

Detection

Automatic flaky test list

A ranked list of your flaky tests, each with a plain-language explanation of the cause.

Agent

Answers your agent can act on

The same report Claude reads before it touches a failing test, via skill or MCP server.

GitHub

Pull request insights

Test insights posted directly on your GitHub pull requests, where the review happens.

Core — fully working

SDK ingestion of dotnet test runs, local and CI
Xping CLI reporting from local history and cloud
Confidence scoring + reliability tiers (Cloud)
Automatic flaky test detection
LLM + rule-based analysis in Xping Cloud
GitHub pull-request insights
Cloud access, unlimited projects

Limited during MVP

– Agent integration (skill / MCP server) shipping during the pilot
– User management — manual seat provisioning
– Billing — handled manually, not self-serve
– Integrations beyond GitHub (GitLab, Slack, webhooks)
– OAuth / 2FA still landing
– Shorter data retention; limited exports
– No SLA or uptime guarantee (pre-production)

Pricing

One flat price to find out.

Pilot — 3 weeks

$99

Flat, one team (up to ~10 users), Team-level limits unlocked. Fully credited toward your first paid month if you continue.

Convert before the pilot ends → 20% off for 6 months.

Apply for the Pilot

Local — free forever

SDK + CLI · no account · unlimited runs · detection, no scoring · history stays on your machine · xping login upgrades in place

How local mode works ↑

Seats are for anyone who reads the results — QA, leads, product. Only developers need the SDK installed.

After the pilot — your live plans

Basic

$19/mo

1 user · 10K exec/mo · 14-day retention

Pro

$49/mo

Up to 3 users · 50K exec/mo · 90-day · AI analysis

Team

$149/mo

Up to 10 users · 250K exec/mo · 1-year · API + GitHub PR

Add-ons: +$10/user · +$15 per 50K tests · +$20 unlimited retention. Annual: Pro $42/mo · Team $129/mo.

See the full pricing & FAQ for add-on and annual-billing details. Not sure what flakiness is costing you? Run the numbers →