Historical Data Availability: A 60-Second Backtest Pre-Flight
You configure a backtest with six pairs across 18 months, hit run, and walk away. The equity curve comes back flat, the trade count is suspiciously low, and the performance period in the results doesn't match what you asked for. The strategy isn't broken — half your pairs were missing data you assumed was there. VolatiCloud's data availability system surfaces exactly what historical OHLCV your runner has, so you know what you're working with before you start anything.
Why Data Gaps Quietly Corrupt Backtests
Backtesting engines work by replaying historical candles in sequence. Freqtrade — the engine that powers VolatiCloud bots — handles missing candles by skipping those periods. When candle data for a pair is incomplete, the engine doesn't stop or warn you prominently. It just doesn't trade during the gaps.
The result is a backtest that looks complete but isn't. A 12-month test that's actually missing 6 months of data on three of your pairs produces misleading statistics:
| Issue | What You See | What It Means |
|---|---|---|
| Incomplete pair data | Low trade count | Strategy couldn't trade during data gaps |
| Missing recent candles | Performance ends before today | Regime changes in recent months are invisible |
| Partial timeframe coverage | Short effective test period | Results reflect a narrow window, not the full range |
| Uneven pair coverage | Some pairs dominate results | Skewed metrics, not representative exposure |
The numbers aren't wrong exactly — they accurately reflect what happened in the available data. But you're drawing conclusions about a 6-month window while believing you tested 12 months. That gap between expectation and reality is where bad strategy decisions come from.
The Runner Data Tab
Every runner in VolatiCloud has a Data tab showing the download status of every pair the runner is configured to track. Each pair appears as a row with its symbol, timeframe, and current status:
- Ready — historical data is fully downloaded and available for backtesting
- Downloading — backfill is in progress; data will be ready shortly
- Pending — queued for download; the runner will process it when capacity is available
- Failed — download failed, typically due to exchange connectivity or an invalid pair symbol
Filter by status using the chip buttons at the top. On a runner with a large watchlist, filtering to "Failed" shows you which pairs need attention immediately — whether that means correcting a symbol name, checking exchange access, or re-triggering a download.
The Progress Header
A summary header above the pair list shows your runner's overall data health at a glance:
- Total pairs configured vs. pairs in Ready state
- A progress bar and percentage
- Active download count
If you open the Data tab and see "38 of 50 pairs ready (76%)," you know before touching the backtest drawer that the 12 pairs still downloading will produce incomplete results. Wait for the downloads to finish, or build your backtest around the 38 ready pairs.
This is the kind of information that used to surface only after a failed or thin run. Now it's visible before you start.
The Data tab is virtualized and paginated. It handles runners with hundreds of pairs without performance issues. Use the search box to filter by pair name in a large watchlist.
Availability in the Pair Picker
The most impactful change for day-to-day workflow is data availability integrated directly into the backtest and hyperopt drawers. When you're selecting pairs to test, each one in the autocomplete picker shows its data availability status inline.
Previously: you'd pick six pairs, click Run, and discover mid-run (or buried in results metadata) that two had no data.
Now: the pair picker uses featured-first ordering — pairs with complete data appear at the top, pairs still downloading next, pairs with no data last. You see at a glance which pairs are ready before you submit.
This also fixes a subtler problem on runners with large whitelists. Previously, the pair picker showed only a limited set of options because it couldn't efficiently query availability across thousands of pairs. The rewritten picker uses server-side pagination and streams results as you scroll, so a runner tracking 38,000 pair/timeframe combinations no longer causes the picker to go blank or return incomplete results.
For more on what to do with backtests once your data is ready, see Crypto Backtesting: Validate Your Strategy Before Going Live.
Data Availability on the Bot Detail Page
The data availability feature also surfaces on individual bot detail pages. A panel on the bot overview shows the data health for each pair the bot is configured to trade. This matters in three situations:
Fresh runners. A bot running on a recently provisioned or reconnected runner may not have finished downloading history for all its pairs. The panel shows whether the data foundation is complete before you rely on the bot's signals.
New pairs added to an existing bot. If you add pairs to a running bot's whitelist, the runner starts downloading data in the background. The panel shows progress so you know when new pairs are ready to trade.
Post-incident recovery. If a runner was offline and missed market data, the panel shows which pairs have coverage gaps and whether backfill is in progress.
How Much Historical Data Is Enough?
The right answer depends on strategy type. Practical minimums for reliable backtests:
| Strategy Type | Timeframe | Minimum History | Rationale |
|---|---|---|---|
| Short-term scalping | 1m–5m | 3–6 months | Many trades needed for statistical weight |
| Intraday | 15m–1h | 6–12 months | Need multiple market regimes |
| Swing trading | 4h | 12–24 months | Fewer daily trades; need more calendar time |
| Daily strategies | 1D | 24–36 months | Each candle is a data point; need hundreds |
| Trend-following | Any | 18–36 months | Must include trending and ranging periods |
| Hyperopt | Any | 24+ months | More data = more constrained parameter search |
The Data tab shows the date range of available candles for each pair, so you can verify coverage before picking your backtest window.
A general rule: your backtest should include at least 200–300 trades to be statistically meaningful. If your configuration produces fewer than that, either your strategy is too selective or your data window is too short.
Running hyperparameter optimization on thin data is more dangerous than running a standard backtest on thin data. Hyperopt finds parameters that fit whatever patterns exist in the available history — including artifacts caused by data gaps. Always verify data completeness before starting hyperopt runs.
A Practical 60-Second Pre-Backtest Workflow
Before submitting a backtest or hyperopt run, this check prevents most data-related failures:
- Open the runner's Data tab — confirm your target pairs show "Ready" status
- Check the progress header — note the overall percentage and whether downloads are active
- Filter by "Pending" or "Downloading" — any pairs here will produce incomplete results if included now
- Open the backtest drawer — the pair picker shows availability inline; build your configuration from Ready pairs
- Verify the date range — confirm available history covers your window plus a warm-up buffer (at least 100+ candles for your slowest indicator period)
If any pairs are still downloading, you have two options: wait for downloads to complete, or narrow the backtest to ready pairs. For exploratory runs, the ready subset is usually fine. For a definitive test you'll rely on for strategy decisions, wait for full coverage.
For a deeper treatment of validating strategy results, see walk-forward optimization and how to avoid overfitting in crypto backtests.
Runner Configuration and Pair Whitelists
Runners only download data for pairs on their configured whitelist. If a pair isn't appearing in the Data tab, it hasn't been added to the runner's configuration.
To add pairs to a runner's data collection:
- Go to the runner's settings (the edit drawer from the Runners list)
- Add the pairs to the pair whitelist for the relevant exchange
- The runner begins downloading historical data automatically
Initial backfill speed depends on the exchange's rate limits and how much history you've requested. For a fresh runner with a large whitelist, expect anywhere from a few minutes (recent 30-day window, small list) to several hours (2-year window, 50+ pairs). Cloud runners on VolatiCloud handle this in the background without affecting your running bots.
One practical note on exchange data limits: different exchanges provide different amounts of historical data through their APIs. Binance typically has 3–5 years of minute-level OHLCV data; smaller exchanges may have 6–12 months. The Data tab shows the actual coverage available for each pair, which reflects what the exchange provided — not what you requested. The market data lake post explains how the underlying download infrastructure works.
Data Quality and Overfitting Risk
More historical data reduces overfitting risk because your strategy parameters must perform consistently across a wider range of market conditions. A parameter set tuned on 6 months that happened to trend strongly may look excellent in backtest but fail when the market enters a sideways or reversing regime.
When you run hyperopt on a runner with 24+ months of data across multiple market regimes — bull runs, corrections, ranging periods, high-volatility events — the optimizer has more constraint. Parameters that work only in trending markets won't survive 2 years of varied conditions. Parameters that survive likely reflect something real about the market structure.
This is why the data availability panel matters for strategy quality, not just run reliability. The question isn't just "did the backtest run?" — it's "did it run on enough data to be trustworthy?"
Check Your Runner Data Availability
The data availability system removes one of the most frustrating blind spots in strategy development: the difference between the backtest you intended to run and the one that actually ran. With the Data tab, progress header, and pair-picker integration, that gap closes. And if you're still setting up your first run, the backtesting feature page on volaticloud.com gives the end-to-end overview of the managed engine before you dive into the docs.
The next time you set up a backtest, check the runner's Data tab first. Sixty seconds of review can save hours of debugging results that looked wrong but were never going to be right.
Check your runner's data availability in the VolatiCloud console, or read the runner documentation to understand how to configure your runner's pair whitelist for complete data coverage.