01
Change the conditions.
Explore test order, available processors, and the race detector across a balanced configuration matrix.
FOR THE TEST THAT ONLY FAILS IN CI
Find the failure
behind the flake.
“It passed on my machine” isn’t a diagnosis.
Vary the configuration. Follow the evidence.
Leave with a command that reproduced it.
GO A small CLI. Zero third-party Go dependencies.
+ CONFIGURATION SCANILLUSTRATIVE FIXTURE
PASSFAIL60 CONFIGURATIONS
FAILURE ISOLATEDTestDrainOrder
ORDER-DEPENDENTShuffled
60%
Unshuffled
0%
$ GOMAXPROCS=8 go test -shuffle=1 -count=1
An illustrative finding. Explore computed evidence below.
01 / OBSERVE02 / COMPARE03 / REPRODUCE ↗
×Configurations,
not guesswork.
not guesswork.
≠Always failing?
That’s not flaky.
That’s not flaky.
⊞Many failures.
Distinct signatures.
Distinct signatures.
↳One next step.
A minimal repro.
A minimal repro.
01 / A SHORTER PATH TO “FOUND IT”
Turn intermittent failures
into something concrete.
Flakescope reruns your Go package under different configurations, then tells you what the failures actually depend on.
02
See the evidence.
Compare failure rates between configurations. A label comes with the observations that earned it.
Shuffle on 18 / 30Shuffle off 0 / 30
03
Reproduce a finding.
Group repeated failures by signature. Get the smallest observed reproducing configuration for each group.
$ go test -shuffle=1 -count=1
02 / THE EVIDENCE ROOM
Break a test.
Understand why.
A hands-on look at a Flakescope report. Choose a fixture, run the matrix, and inspect every finding.
Browser simulation · synthetic test fixtures
Two independent failure axes. One clear place to investigate.
Example report ready
60 / 60 configurationsCONFIGURATION MATRIXONE CELL / ONE CONFIGURATION
No intermittent failuresIntermittent failurePendingAlways-failing tests excluded from cell color
TESTS OBSERVED—
FLAKY—
ALWAYS FAIL—
NEVER FAILED—
Have a real run? Import its flakescope --json report to explore the same view. Files stay in your browser.
03 / TRUST THE OBSERVATIONS
A label should come
with receipts.
A shuffled failure alone doesn’t prove order dependence. Flakescope compares rates, checks sample sizes, and leaves uncertainty visible.
WHAT MAKES A SIGNAL?ALL THREE CHECKS
4+
Observations in each arm
Enough samples on both sides to make a comparison.
2×
Difference in failure rate
The higher arm fails at least twice as often.
2z
Pooled two-proportion threshold
The observed difference clears a z-score of two.
No clear signal?
undetermined is an honest answer.Same test. Different bugs.
Failures are grouped by normalized signature. Addresses and durations are normalized; meaningful integers stay intact. Prefer a visible split over silently merging two bugs.
got 1234, want 1000≠got 7, want 1000A useful command, with a precise promise.
“Minimal” means the smallest configuration among those that actually failed, measured against the baseline. Each failure cluster gets its own command.
Configuration replay is not goroutine scheduler replay. Nondeterministic failures may not repeat on every attempt.
04 / FROM THE DEMO TO YOUR TERMINAL
Take the next
failure personally.
Point Flakescope at your Go package. Start with twenty configurations. Increase the sample when the signal is rare.
Read the full documentation ↗YOUR TERMINAL⌘
# 1. Install the CLI
go install github.com/AarinB1/flakescope/cmd/flakescope@latest# 2. Inspect your package
flakescope --runs 60 ./internal/queue# 3. Export a report for the playground
flakescope --runs 60 --json ./internal/queue > report.json ZERO THIRD-PARTY GO DEPENDENCIES
A FEW GOOD QUESTIONS
Before you
rerun.
Is this playground running my Go tests?+
No. The built-in scenarios are deterministic synthetic fixtures, evaluated in JavaScript. They demonstrate Flakescope’s documented reporting concepts. To inspect your own tests, run the CLI locally and import its JSON report.
Does Flakescope replay goroutine scheduling?+
No. It varies configurations: test order, GOMAXPROCS, and the race detector. It does not control or replay a particular goroutine interleaving. A reproducing configuration is evidence of a failure under those settings, not a guarantee of repetition.
Why is a test marked “undetermined”?+
The test both passed and failed, but no axis cleared the minimum observation count, rate ratio, and statistical threshold. Increase --runs for a rarer failure. The CLI reports the smallest failure rate the run could resolve when it can compute one.
What does the exit code tell CI?+
Exit 0 means no flaky tests were found. Exit 1 means flaky tests were found. Exit 2 means Flakescope itself failed, the package did not build, or no configuration completed. Always-failing tests are reported separately and do not change the flakiness exit code.
What makes a reproduction “minimal”?+
Among configurations that reproduced the same cluster, Flakescope prefers the fewest changes from the default, then lower GOMAXPROCS, race off, and the lowest shuffle seed. It is a minimum over observed failures, not a search of every possible configuration.
Is an imported report sent anywhere?+
No. The page reads the selected JSON file in your browser. There is no upload service, analytics, external script, or account. Use Export to download the report you are viewing.