The execution logs are where you find out why a bot did what it did — including why it correctly did nothing. Positions, order book and P&L tell you the outcome; the logs tell you the reasoning.
The four screens
| Screen | What it shows | Use it when |
|---|---|---|
| Execution logs | Every decision the strategy made, with the broker's reply | You want to know why something did or did not happen |
| Positions | What you are currently holding | You need the live state right now |
| Order book | Every order sent and its status | You need to confirm an order actually reached the broker |
| P&L tracker | Profit and loss over time | You are reviewing performance, not debugging |
Reading the execution logs
The logs record each evaluation, not just each trade. That is what makes them useful: a day with no trades still produces a trail showing what the strategy checked and what it concluded.
What gets recorded
Typical entries you will see:
- The entry condition was evaluated and not met — with the values it compared.
- An order was constructed and sent, with the exact parameters.
- The broker accepted or rejected it, with the broker's own message preserved.
- A stop loss, target or trailing stop triggered.
- The strategy squared off at its exit time.
The broker's raw message is kept rather than replaced with a friendly one, because the exact wording is what identifies the cause of a rejection. A generic "order failed" would be easier to read and useless to act on.
The entries worth reading most
The most valuable log entries are the boring ones. A record showing the condition was checked and not met is what proves the strategy ran correctly on a day it did nothing — which is the difference between a working system and a silent failure.
Reading a multi-leg entry in the logs
A four-leg entry produces more log output than people expect, and knowing the shape makes a partial fill obvious rather than hidden.
You should see the entry condition evaluated once, then four separate order constructions, then four separate broker responses. Four of each. If you count three responses against four constructions, one leg never got an answer, and that is the thing to investigate.
Counting the entries
What each pattern means:
| What you count | What it means |
|---|---|
| 4 constructed, 4 accepted | Clean entry, position as designed |
| 4 constructed, 3 accepted | Partial fill — check positions immediately |
| 4 constructed, 0 accepted | Setup problem — read the first error |
| 1 condition, 0 constructed | Condition not met, working correctly |
| Nothing at all | The bot was not running |
The second row is the one worth building a habit around. A partially filled multi-leg structure will not announce itself anywhere else, and the position it leaves behind can have a very different risk profile from the one you tested.
Order book: today versus history
Broker APIs generally return only the current day's orders. To make past dates viewable, the full order book is captured after each market close and stored.
Why past dates behave differently
That means today's order book comes live from your broker, and past dates come from the stored snapshot. If you are looking for an order from last week, you are reading the snapshot.
One practical consequence: an order placed and cancelled within the same day appears in today's live view but may not survive into the end-of-day snapshot, depending on what the broker reports at close. For same-day forensics, look while it is still today.
Positions
Positions show what you are holding right now. For a single-leg strategy this is unremarkable. For a multi-leg structure it is the screen that tells you whether you are holding the strategy you designed.
What to look at on a normal day
Most days need thirty seconds of attention, not a review. The question is only whether the system did what it was supposed to.
- Did every bot that should have run, run? Count them.
- Did the ones that entered, exit cleanly at their exit time?
- Were there any rejections?
- Are positions flat at the close, if the strategies are intraday?
If those four are satisfied, the day was operationally fine regardless of the P&L. Separating the operational question from the performance question is what stops a losing day turning into an unnecessary change to a working strategy.
P&L tracker
Daily P&L is captured after the close rather than computed on demand, which keeps historical figures stable instead of shifting as prices move.
Live and paper P&L are stored separately and never combined. The number you see for live trading is only live trading.
Why they are never merged
That separation matters more than it sounds. Combining them would let a strong paper month disguise a weak live one, which is exactly the self-deception a P&L screen should make harder rather than easier.
Debugging order
1
Start with the logs
They tell you whether the strategy decided to act at all. Most questions end here.
2
If it decided to act, check the order book
This confirms whether the order reached the broker and what the broker said.
3
If the order filled, check positions
Particularly for multi-leg strategies, where a partial fill leaves an unintended structure.
4
Only then look at P&L
P&L is the outcome, not the explanation. Debugging from it leads to wrong conclusions.
A worked debugging walkthrough
Reading the screens in the right order turns most problems into a two-minute answer. Here is the same question — "why am I down today when the backtest said this should have been a good day?" — worked through properly.
1
Open the logs for that strategy and date
Confirm the bot was running at all. An empty log means it was never started, and nothing else matters.
2
Find the entry evaluation
The log records what the condition compared and what it concluded. Confirm it fired at the time you expected.
3
Find the order construction entry
This shows the exact legs, strikes and quantities the engine built. Compare them against what you intended.
4
Find the broker's reply for each leg
This is where a partial fill shows up. Four legs sent and three accepted is a different position from the one you designed.
5
Check positions for that period
If a leg was rejected, positions tell you what you were actually holding and for how long.
6
Only now look at P&L
By this point you know whether the loss came from the strategy being wrong or from the execution being incomplete.
The distinction that walkthrough produces matters. A strategy that performed badly needs reviewing. A strategy that was executed incompletely needs the execution fixed, and reviewing the strategy would be chasing the wrong problem.
What to check weekly
Daily checks catch failures. A weekly pass catches patterns, which is a different and slower-moving category of problem.
- How many days did each bot actually run, against how many it should have?
- How many orders were rejected, and for what reason?
- Did any multi-leg strategy end up partially filled?
- Is the live P&L drifting further from the backtest than it was a month ago?
- Are there days with completely empty logs?
That last item is the one worth being strict about. A string of empty logs means the morning routine is not holding, and no amount of strategy work compensates for a bot that is not running. Deploy versus start covers the fix.
How long logs are kept
Execution logs and the daily snapshots are retained so you can review a strategy's behaviour over time rather than only on the day. That matters when you are deciding whether a run of bad days is noise or a pattern.
If you are comparing a live period against a backtest for the same dates — which is the right way to measure your real execution cost — the stored history is what makes that comparison possible.
The short version
Debug from the logs outward, never from the P&L backwards.
- Logs record decisions, including the correct decision not to trade
- The broker's raw error message is preserved because the wording identifies the cause
- Count log entries on a multi-leg entry — four legs should produce four responses
- Today's order book is live; past dates come from an end-of-day snapshot
- Live and paper P&L are never combined
A thirty-second check after your exit time — did everything that should have run, run, and were there rejections — separates operational problems from performance ones before they compound.
Frequently asked questions
Count the log entries. Four legs should produce four order constructions and four broker responses. Three responses against four constructions means a leg is missing.
A thirty-second check after your exit time is enough: did the bots that should have run, run, and were there any rejections? That separates operational problems from performance ones.
So historical figures stay stable instead of shifting every time prices move. A number that changes when you look at it twice is not useful for reviewing past performance.
The execution logs. They record each evaluation including the ones where the entry condition was not met, so a day with no trades still leaves a trail.
Yes. Logs, positions and P&L are kept separate for live and paper, and the totals are never combined.
Broker APIs typically return only the current day. Past dates are served from a snapshot captured after each market close.
Daily figures are captured after the market close, which keeps historical values stable rather than shifting with live prices.
The broker likely rejected it. The log keeps the broker's own message, which names the reason — usually margin, session or IP.
The logs, always. They distinguish between a strategy that decided not to act, one that acted and was rejected, and one that was never running at all. Those three look identical from the P&L screen.
Start with a free 3-day trial
Build a strategy, backtest it and run it on paper — no broker, no IP and no money needed to try it.
