> For the complete documentation index, see [llms.txt](https://docs.tradesurge.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tradesurge.co/platform/strategies/backtest.md).

# Backtest a strategy

Run a strategy version over historical candles and read the result in R, including a sweep of up to 64 parameter sets.

A backtest runs one strategy version over historical candles and shows how it would have traded. Results are in R, with trading costs included. It is the first check before a strategy goes anywhere near an account.

{% hint style="info" %}
**Early access.** Backtesting opens with the alpha, for invited traders.
{% endhint %}

## What you need

* An uploaded strategy version.
* The market and the date range you want to test.
* The parameter values, or ranges, you want to try.

## Run a backtest

{% stepper %}
{% step %}

### Open the strategy version

Go to Strategies and open the version you want to test.
{% endstep %}

{% step %}

### Choose the market and window

Pick the pair and the date range.
{% endstep %}

{% step %}

### Set the parameters

Enter one set, or a grid of sets to sweep. A sweep runs up to 64 parameter sets.
{% endstep %}

{% step %}

### Read the results

Compare each set on the numbers below.
{% endstep %}
{% endstepper %}

## What you see

| Name                 | What it means                                                          |
| -------------------- | ---------------------------------------------------------------------- |
| **Expectancy (R)**   | Average result per trade. The number that matters most.                |
| **Win rate**         | Shown for context only. It never decides anything.                     |
| **Max drawdown (R)** | The deepest fall from a peak, in R. Compare it with your firm's limit. |
| **Equity curve**     | Cumulative R over the test window.                                     |

{% hint style="warning" %}
The best set in a sweep is almost always flattered by chance. A strong backtest is a reason to test further, not proof of an edge. That is why a backtest alone can never promote a strategy to live money.
{% endhint %}

## Good to know

* Costs come from one fixed cost model that is stamped on every run, so results cannot be tuned by changing fees.
* Backtests run inside the same restricted sandbox as every other strategy run.

## Next steps

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Simulator</strong></td><td>Test these results against a firm's rules.</td><td><a href="/platform/simulator.md">Simulator</a></td></tr><tr><td><strong>Autotrade and the promotion ladder</strong></td><td>What a strategy needs beyond a backtest.</td><td><a href="/platform/strategies/autotrade.md">Autotrade and the promotion ladder</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.tradesurge.co/platform/strategies/backtest.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
