How Long to Run an A/B Test - A Practical Duration Guide (2026)

“How long should I run this test?” is the most common question in experimentation, and the honest answer frustrates people the first time they hear it. The duration of an A/B test is not something you choose - it is something you calculate. It falls out of how big an effect you want to catch, how much traffic you have, and the rhythm of your business. Picking a number of days because it feels right is how tests get called early, underpowered, and wrong.

Duration is an output, not an input

The length of a test is determined by three things you decide during design.

• Your baseline conversion rate - where the metric sits today.
• Your minimum detectable effect - the smallest lift worth catching. See minimum detectable effect explained.
• Your traffic - how many eligible users you get per day.

A power calculation turns the first two, plus a significance level (usually 5 percent) and a power target (usually 80 percent), into a required sample size. Then:

duration (days) = required sample size / daily eligible users

That is the arithmetic. If your calculator says you need 40,000 users per variant, that is 80,000 total, and you get 10,000 eligible users a day, the test needs roughly eight days - which you round up to two full weeks for reasons we get to next. To get the sample size itself, see how to calculate sample size for A/B testing.

The lever people reach for - “let us just run it two weeks” - has it backwards. The MDE and traffic set the length; the calendar only tells you when that length elapses.

Why the MDE dominates the timeline

The single biggest driver of how long a test takes is how small an effect you insist on detecting. Sample size scales roughly with the inverse square of the MDE, which has a brutal consequence - halving the effect you want to detect roughly quadruples the traffic, and therefore the time.

A test powered to catch a 10 percent relative lift might finish in a week. Demand it catch a 5 percent lift and you are looking at a month. Demand 2 percent and you may need a quarter. This is why setting the MDE to “the smallest lift worth shipping” rather than “the smallest number I can imagine” is the difference between a test that concludes and one that never does.

Always run full business cycles

Even once the arithmetic gives you a number of days, one rule overrides a naive division - run at least one full business cycle, and in whole-week increments.

User behaviour is not uniform across the week. Weekend visitors often browse and convert differently from weekday ones. B2B traffic collapses on Saturdays. Consumer shopping spikes on paydays and weekends. A test that ran Monday to Thursday has sampled a biased slice of your audience, and its result will not hold when the missing days return.

Running in whole weeks guarantees both variants see every day of the cycle equally. If your sample completes mid-week, let it finish the week rather than stopping on a Wednesday. For products with monthly rhythms - payroll, subscriptions, billing cycles - consider whether a single week even captures the pattern.

Why calling a test early breaks it

The most damaging duration mistake is not running too long. It is stopping the moment the result looks significant. This is the peeking problem, and it quietly wrecks more tests than any other error.

Here is why it is so dangerous. Early in a test the data is noisy, and a noisy metric wanders across the significance line by chance far more often than the 5 percent you signed up for. If you watch continuously and stop the instant you see “significant,” your real false-positive rate can climb past 20 or 30 percent. You are not detecting a winner - you are catching noise at its loudest moment. The full mechanism is in sequential testing and the peeking problem.

There are two legitimate ways to run a test:

1. Fixed horizon. Commit to the sample size, do not peek at significance, read the result once at the end. Simple and correct.
2. Sequential or always-valid statistics. Use an engine designed for continuous monitoring, which adjusts the maths so early looks do not inflate false positives. This lets you stop early honestly.

Mixing them - using fixed-horizon maths but stopping whenever you like - is the trap. Pick one and stick to it.

What about running too long?

Overrunning is a milder sin but not free. Past your planned sample and full cycles, extra days rarely make a result more trustworthy, and they cost you the traffic your next experiment needs. Very long tests also accumulate risks - sample ratio mismatch from cookie churn, novelty effects fading, and users being re-bucketed. The target is exactly long enough, not as long as possible.

A quick reference

Situation	Guidance
High-traffic page, sizeable MDE	Often 1 to 2 weeks, still run full weeks
Low-traffic flow	Weeks to a month - or raise the MDE
Weekly business rhythm	Whole-week increments, minimum one week
Monthly billing rhythm	Consider a longer cycle to capture it
Result looks significant on day 2	Ignore it unless you use sequential stats

Where the tooling helps

Statsig sizes the test and tracks progress toward the target sample, with unlimited free flag and config checks on every tier - so duration is driven by the maths, not a guess. Optimizely built its Stats Engine around always-valid inference, which is exactly the tooling that makes early stopping legitimate, on a free Rollouts tier with sales-led pricing above. GrowthBook ships a power calculator on its Pro tier and, being warehouse-native, computes duration against your real traffic.

The bottom line

Calculate the sample size, divide by traffic, round up to whole business cycles, and do not stop early unless your stats engine is built for it. A test run to a real sample over full cycles gives you a number you can trust. A test called on a good-looking Tuesday gives you a story. Pair this with how to design an A/B test and how to run an A/B test to plan the whole thing end to end.