Run and inspect a batch of backtests

View full-size screenshot ↗

Decide what each row represents#

A Batch Backtest row is one complete native Backtest request. It can include several instruments and simulated accounts, currency routes, cost and margin settings, dates and algorithm parameters. The batch does not automatically multiply a list of symbols into tests. Add the exact runs you want to execute.

This is useful for a deliberately designed comparison: the same strategy on an equity and a currency pair, several fixed parameter variants, or a baseline versus spread-stress case. Each instrument still needs its own verified economics. Copying one request and changing only the ticker can leave an invalid lot size, multiplier or account currency.

Build the batch#

1. Add New Batch Backtest to the workspace. It provides Batch Backtest Config and Batch Backtest Results.
2. Set an optional Name that describes the research question and period.
3. Set Concurrent to the number of child backtests allowed to run at once. The default is four; capacity and memory may justify a smaller value.
4. Choose Add to open Add Exact Native Backtest. This embeds the normal Backtest configuration form. Complete the algorithm, simulated account, instruments, period and execution assumptions.
5. Use Go to first when the footer names missing values. Add to batch adds the complete request. Add and start another keeps the dialog and its fields so you can create another deliberately edited case.
6. Review Requests (n). Its rows show algorithm, symbols, account/instrument/parameter counts, dispatch and UTC period. Duplicate or remove rows as needed.
7. Choose Start batch or ⌘/Ctrl+Enter after checking all rows and concurrency.

The batch form locks while starting or running. A progress banner and separate Cancel action appear. Cancelling asks for confirmation and shows the server's response; the client does not assume a cancellation succeeded.

Edit exact requests safely#

The row menu's Edit request JSON… exposes the complete child request. The editor checks JSON syntax, model structure, algorithm, UTC range, dispatch, warmup/history settings and the contract graph. Its error points towards the problem rather than silently filling a different request.

Use the editor for a known, explicit change. Preserve IDs and account references when they still describe the same contract; replace dependent fields when the feed or instrument changes. An unknown field or incomplete graph can make the request invalid. The ordinary form is usually easier for an initial configuration.

The exact-request inspector is read-only and offers Copy JSON and Add to builder as new row. This provides a useful way to retain the configuration behind a past result before changing it. A rerun creates new work; it does not rewrite the original evidence.

Read the summary and child results#

The Results panel always has a Summary tab. Its KPIs include completed tests, average return, average profit factor, total trades and the best and worst child outcomes. These are comparison statistics. They are not the equity curve or drawdown of a simultaneously funded portfolio.

The table shows algorithm, instrument/venue/account context, status or error, return, maximum drawdown, time-weighted profit, profit factor, win rate, trades and final equity. Click a column to sort; missing metrics remain separate rather than becoming favourable zero values. Use the text filter to narrow a large batch; Escape clears it.

Open a completed row by double-clicking or pressing Enter. Its result tab contains the normal Backtest Report, with Previous, Next, Inspect request and Open in Backtest Item above it. An algorithm tab can collect the rows for one algorithm. The Summary tab stays available while these tabs are open.

Treat partial completion explicitly#

A batch can finish with failed children. The client may present a partially completed batch under the completed state, so inspect the completed/failed/total counts and each status row. A green result in one row does not repair another row's missing history or rejected contract.

A failed child can show No completed result artifact exists. Use Rerun as new row after correcting its request. Do not expect an equity chart for a child that never produced one. A restored tab whose child is absent shows Result not found; return to Summary and select a valid row.

For example, if two equity tests complete but a futures test fails, inspect the futures symbol, exact contract, quantity grid and date coverage. Correct that child and rerun it. There is no need to repeat the successful rows merely to obtain a uniform status label.

Reopen and recover#

History opens a saved batch. With no batch loaded, Open last batch restores the newest available entry. WebSocket updates trigger server-snapshot reloads; reconnecting reconciles history and the displayed batch.

Closing or moving the workspace item leaves the batch running on the server. Reopen its history to follow it. Whole-item moves create fresh view state and can discard unsubmitted builder rows, so preserve exact requests before moving a prepared batch. A desktop Pop out keeps the panel in its item and is a different operation from moving it.

If starting fails, preserve the request and read the error before retrying. If the API changed, check you are using the intended server and its history. For remote execution, verify the child request's destination and the worker connection; the batch concurrency control does not prove that every requested remote worker is ready.