Choosing a test period
An earlier FAQ said "Custom date ranges are not currently configurable from the strategy builder." That is wrong. Saying "backtest the last 6 months" has always worked.
The same answer also said the default period is chosen to suit your timeframe. It is not, the default is a fixed window, identical for every timeframe and every asset class.
The default window
With no period stated:
| From | 1 January 2024, 00:00 UTC, fixed |
| To | Now, floored to the top of the current hour |
That is the same for a 1-minute crypto strategy and a daily equity strategy. There is no timeframe-dependent default.
Why the end is floored to the hour
The price-data fetch cache is keyed on the end timestamp. A per-second end value would give every worker process a different key for the same strategy, so each would re-fetch the full range, 30 to 50 seconds for a 2.5-year 1-minute series, and write a duplicate cache entry.
Flooring to the hour means every backtest within the same UTC hour, on any process, shares one key and hits the cache. The only behavioural effect: an open-ended window ends at the top of the current hour rather than the current second.
The 1 January 2024 floor
No backtest can start earlier. A request before it is rejected with the earliest supported date named:
We currently support backtests from 01 Jan 2024 onward. Please choose a start date on or after that date.
The floor is a data-availability boundary, not a per-asset-class limit. Equity and crypto share it; so does every timeframe.
Every backtest on this platform is a test against market conditions from January 2024 onward. That window contains particular regimes. A strategy validated only on it has not been tested against conditions outside it. And as the floor recedes into the past, the window lengthens but its start does not move.
This is the most important structural limitation of backtesting here, and it is why the honest question is not "did it work" but "did it work in this period, and is that period like the one I am about to trade".
Stating a period
Relative
backtest the last 6 months
backtest the last 90 days
run it on the last 3 months
Counted back from today. The state passed to the model carries today's date, which is what makes a relative duration answerable.
Without the current date, the router could not know what "now" was, so it omitted the period entirely and the run silently fell back to the default window. Absolute ranges worked fine, which is why only relative durations appeared to be ignored. Both work now.
Absolute
backtest from 2025-01-01 to 2025-06-30
backtest from jan 2026 to march 2026
One bound only
State either bound and the other takes its default: an omitted start becomes 1 January 2024, an omitted end becomes now.
Validation
| Condition | Result |
|---|---|
| Start before 1 Jan 2024 | Rejected, earliest date named |
| Start on or after end | Rejected |
| End in the future | Silently clamped to now |
| Start ≥ clamped end | Rejected |
Only the future-end case is silent, because clamping is unambiguous.
Indicator warm-up
An indicator needs history before it produces a value. A 200-period moving average has no value until the 200th bar.
When you state a window, the fetch start is moved earlier than your simulation start by a computed padding, so indicators are warm when the tested period begins. Padding depends on the timeframe, the indicators in the strategy and the objective. And it is clamped to the 1 January 2024 floor.
When you use the default window, data is fetched from the configured start as-is. The window is long enough that warm-up is absorbed at the front.
The consequence worth knowing: a stated window that starts close to 1 January 2024 may not get its full warm-up padding, because the padding cannot cross the floor. A 200-period daily indicator on a window starting 15 January 2024 has 15 days of history to warm on, not 200. That does not error. It produces a strategy whose entry cannot be true early in the window.
Other things you can set on a run
| Say | Sets |
|---|---|
backtest with 5 lakh | Starting balance (default 10,000 in the quote currency) |
backtest with 10 bps slippage | Slippage override |
backtest with zero commission | Commission override, an explicit 0.0 is honoured |
Starting balance matters more than it looks: percentages are meaningless without an absolute, and position sizing interacts with lot sizes and quantity steps. A ₹10,000 balance on an instrument trading at ₹2,800 buys three shares, and three-share arithmetic is not representative of what you would actually run. See Fees & charges
Choosing well
The floor bounds what is possible. Within it, these are the questions that matter.
Is it long enough to produce enough trades?
Under 20 trades and the result means very little; the grading system gives sample size its own component for this reason. See Strategy grades
| Timeframe | A reasonable minimum |
|---|---|
| 1m - 5m | 90 days |
| 15m - 1h | 6 months |
| 4h - 1d | The full available window |
Does it contain more than one market condition?
A strategy tested only through a directional run tells you nothing about how it behaves in consolidation. Check whether your window included both, the market alignment label in the assessment is one input to that, and looking at the index over the window is another.
Are you choosing the window because of the result?
The trap. Testing several windows and reporting the best is selection, not validation.
Choosing the window that produces the best number is the same error as choosing the parameters that produce the best number, and it is harder to notice because it feels like due diligence.
Pick the window for a stated reason ("the longest available", "the last six months because that is my intended holding regime") and then accept what it gives you.