Use this backtesting journal template to document strategy rules, data, costs, results, revisions, and decisions without letting hindsight distort your research.
Quick Answer
A backtesting journal should record the hypothesis, complete strategy version, market and data scope, execution assumptions, test results, observations, and final decision for every experiment. Create the entry before reviewing the outcome, then preserve it instead of overwriting weak results. The main limitation is that documentation cannot correct bad data or unrealistic execution modeling; it only makes those choices visible and easier to audit.
Key Takeaways
- Treat each backtest as an experiment with a question defined in advance.
- Save the exact strategy version rather than describing it from memory.
- Record costs, fill timing, position sizing, and other execution assumptions.
- Separate observations from decisions so an interesting pattern does not become an unsupported rule.
- Preserve failed tests because they prevent repeated work and hindsight-driven storytelling.
- Require stronger validation before promoting a revised strategy toward paper or live trading.
What a Backtesting Journal Is For
A backtesting journal is a research log, not merely a list of trades. A trade log shows what the simulator did. The journal explains why the test existed, what assumptions governed it, what changed from the prior version, and what conclusion the evidence supports.
Without that record, strategy research becomes difficult to reconstruct. You may remember that one moving-average variation looked promising but forget which data period, fee model, exit rule, or position-sizing method produced the result. You can also end up repeating discarded tests or presenting the final strategy as if its rules had been chosen before seeing the data.
The journal creates a chain of evidence:
idea → specification → test configuration → result → interpretation → next decision
That chain is useful even when the result is negative. A documented rejection narrows the research space and stops the same weak idea from returning under a different name.
Backtesting Journal Template
Use one entry for each meaningful experiment. If you change an entry condition, exit, market universe, cost assumption, or parameter-selection method, create a new version.
1. Research question
Write one question the test is designed to answer.
Examples:
- Does a volume filter improve a breakout strategy after costs?
- Does the strategy remain viable outside the period used to design it?
- How sensitive is maximum drawdown to the stop distance?
Avoid broad goals such as “find a profitable strategy.” A narrow question makes the result easier to interpret.
2. Hypothesis and decision rule
Record what you expect and what evidence would change your decision. Define this before running the test.
A decision rule might say that a filter will be retained only if it improves risk-adjusted results across multiple periods without sharply reducing the trade count. This is better than adopting the filter because one chart looks smoother.
Thresholds are research choices, not universal standards. Set them according to the strategy, sample size, costs, and intended use.
3. Strategy version
Save the complete rule set or link it to an immutable version. Include:
- instruments and market universe;
- timeframe and permitted trading hours;
- setup and entry conditions;
- order type and entry timing;
- stop, target, trailing, and time exits;
- position-sizing method;
- maximum concurrent positions;
- conflict and edge-case handling.
Use clear version labels such as breakout-v1.2. State exactly what changed from the previous version.
4. Test configuration
Record the details needed to reproduce the run:
- test date and software version, if relevant;
- data source, date range, and bar or tick resolution;
- in-sample and out-of-sample boundaries;
- commissions, spread, slippage, and funding assumptions;
- starting capital and sizing rules;
- parameter values or sweep ranges;
- treatment of missing data and corporate actions;
- fill model and same-bar order sequencing.
A result is not reproducible if these assumptions are missing.
5. Results
Capture more than net return. Relevant fields commonly include:
- number of trades;
- win rate and average win/loss;
- expectancy per trade;
- profit factor;
- maximum drawdown;
- exposure and average holding time;
- performance by period, instrument, or regime;
- estimated trading costs;
- longest losing sequence.
Metrics should be interpreted together. A strong headline return may depend on concentrated exposure, a small sample, or an unacceptable drawdown.
6. Audit notes and decision
Inspect selected trades and document anomalies, rejected signals, suspicious fills, and mismatches between the written rules and implementation.
Finish with one status:
- Reject: the hypothesis failed or the test was invalid.
- Revise: a specific issue justifies another version.
- Retest: the implementation or data needs correction.
- Validate: the result merits out-of-sample or walk-forward testing.
- Pause: the evidence is inconclusive.
Do not use “promising” as a substitute for a decision.
A backtest's equity curve and trade-by-trade log.
How to Use the Backtesting Journal Template
Step 1: Freeze the question before testing
Write the hypothesis, strategy version, primary metric, and decision rule first. This reduces the temptation to redefine success after seeing the report.
Step 2: Run a baseline
Test the simplest defensible version before adding filters. The baseline shows whether later complexity contributes useful information or merely improves historical fit.
Step 3: Change one research concept at a time
A concept may involve several linked rules, but avoid changing entries, exits, sizing, and costs in the same comparison. Otherwise, you cannot identify what caused the difference.
Step 4: Record the result before interpreting it
Copy the configured assumptions and core metrics into the journal. Then add observations. Keeping those stages separate makes it harder to omit inconvenient evidence.
Step 5: Audit representative trades
Review winners, losers, trades near the test boundaries, and cases where multiple orders could execute on the same bar. Confirm that signal timing, fills, costs, and exits match the specification.
Step 6: Make and preserve the decision
Assign a status and explain why. Never replace an old entry when creating a revision. The sequence of failed and successful versions is part of the evidence.
Step 7: Escalate validation gradually
A favorable development-period result is a reason for further testing, not deployment. Move through unseen data, parameter sensitivity checks, walk-forward analysis, stress scenarios, and controlled paper trading as appropriate.
Configuring a backtest in Kvants Studio.
Worked Example: Testing a Volume Filter
Suppose the baseline buys a completed-bar close above the highest high of the prior 20 bars and exits at a predefined stop or target. Version 1 has no volume condition.
The research question is: Does requiring volume above its 20-bar average improve the strategy without making the result dependent on a small number of trades?
The journal entry records both versions, the same market universe, date range, costs, sizing, and fill assumptions. Only the volume rule changes.
After testing, the filtered version has fewer trades and a smaller drawdown, but its apparent improvement comes mostly from one instrument during one period. The proper journal decision may be Pause rather than Validate. The filter has produced a useful observation, but the evidence does not yet show that it generalizes.
A follow-up entry could test the same fixed rule on unseen data and examine results by instrument and period. It should not quietly alter the volume length until the historical result looks better.
Common Backtesting Journal Failure Modes
Recording only successful tests
This creates survivorship bias in the research history. Preserve rejected ideas and the reasons they failed.
Overwriting strategy versions
If the current rules replace the original rules, earlier results can no longer be reproduced. Create a new entry and describe the change.
Logging metrics without assumptions
Profit factor or drawdown means little if the costs, sizing, date range, and fill model are unknown.
Turning every observation into a filter
Post-test observations are hypotheses for another experiment. Treating them as established rules encourages overfitting.
Comparing unequal tests
Two variants cannot be fairly compared if they use different universes, periods, cost models, or risk. Hold the surrounding configuration constant unless that configuration is the subject of the test.
Backtest results with metric tiles and gate coaching.
Using the Journal With Kvants
Kvants Studio turns plain-English trading ideas into editable, auditable strategy logic. That makes the strategy specification a natural attachment to each journal entry rather than a description reconstructed after the test.
Backtests run on NautilusTrader’s event-driven engine. Kvants also supports parameter sweeps, walk-forward analysis, crisis-stress validation, and controlled paper and live workflows for stocks and crypto research. Record each run’s strategy version, configuration, result, and decision in the same journal structure.
The journal remains important because no platform can decide whether your hypothesis was sensible or whether a revision was motivated by evidence. The Kvants documentation can help you understand strategy creation and export workflows, while the journal preserves your reasoning across those stages.
Frequently Asked Questions
Is a backtesting journal the same as a trade log?
No. A trade log records simulated entries, exits, sizes, and outcomes. A backtesting journal records the research question, strategy version, configuration, summary results, interpretation, and decision. Keep both because they answer different questions.
Should I journal every parameter sweep?
Record the sweep definition, parameter ranges, selection method, and complete result artifact. You do not need a separate narrative for every combination, but you should document why a candidate was selected and whether it was tested on unseen data.
What format should I use?
A spreadsheet, database, or structured document can work. The important requirements are consistent fields, stable version labels, searchable entries, and links to the strategy logic, reports, and trade-level output.
How often should I update the journal?
Create the hypothesis and configuration before the test. Add results and audit notes immediately afterward, then record the decision before starting another revision. Delayed entries invite memory errors and hindsight.
Can a backtesting journal prevent overfitting?
It cannot prevent overfitting by itself. It can reveal repeated parameter changes, post-result rule creation, and reuse of supposedly unseen data. Proper sample separation, sensitivity testing, walk-forward analysis, and realistic assumptions are still necessary.
Risk Note
This article is educational and is not investment advice. Backtested performance does not guarantee future results. Data errors, model assumptions, changing markets, liquidity, costs, and execution differences can materially affect live outcomes.
