A cBot decision log is auditable when it connects the signal, the rule that allowed or blocked it, the order attempt and the resulting platform event. A P&L line tells you the ending; it cannot tell you why the cBot did, or did not, act.
That distinction matters after a missed trade, an unexpected order or a restart. If the only record says that a position closed at a loss, the important questions are still open: which condition fired, which guardrail ran, what parameters were active, and whether the platform accepted the request.
Start with the decision chain, not the trade result
A useful audit trail follows one decision from observation to outcome. It does not need to be a novel database. It needs stable identifiers and a clear sequence.
| Stage | Record | Why it belongs in the trail |
|---|---|---|
| Context | time, symbol, cBot instance or run identifier, timeframe | Separates one evaluation from another. |
| Signal | named condition and the input state it evaluated | Makes the entry idea inspectable rather than implied. |
| Guardrail | risk, session, spread, position-limit or duplicate-order check | Explains both allowed and blocked actions. |
| Request | intended side, volume, order type and protective settings | Preserves what the cBot asked the platform to do. |
| Outcome | returned status plus order or position identifier where available | Lets the request be reconciled with what the platform recorded. |
The goal is not to log every price update. That usually produces noise faster than evidence. Log the events that change a decision: a signal becomes eligible, a guardrail rejects it, an order is submitted, or the order state changes.
Use cTrader events as the reconciliation points
cTrader documents lifecycle handlers including OnStart, OnTick, OnBar, OnStop and OnException, and its examples use Print() to write messages to the cBot log. That gives a cBot natural places to record startup context, evaluated conditions and failures without treating the log as proof of performance. Read the cBot lifecycle documentation.
The order trail needs a second source of truth. cTrader also documents position and pending-order events, including opened, modified and closed positions, alongside created, modified, filled and cancelled pending orders. Its documentation notes that these events can reflect manual activity as well as cBot activity, so an audit trail should filter or label its own records rather than assume every event belongs to the cBot. Read cTrader's trading-event documentation.
A simple rule follows: write a record before the request, then write another when the relevant event arrives. If the two cannot be matched, keep that mismatch visible. It is a review item, not something to smooth over in a weekly summary.
A minimal record that a human can actually review
The following is a record shape, not a complete cBot implementation. Names can differ; the relationship between them should not.
run_id: london-orb-2026-10-02-a
symbol: EURUSD
stage: guardrail
signal_id: 8f2c
result: blocked
reason_codes: session_closed, duplicate_order_check_passedThe record is useful because it answers a specific question: why was there no order for signal_id: 8f2c? If an order is allowed, carry the same signal_id into the request record and then attach the platform identifier returned by the outcome event. Do not substitute a vague message such as “trade failed.” That turns a review task into a guess.
For a restart, write a fresh run identifier and a reconciliation record before the cBot evaluates a new entry. The practical concern is not merely whether the process came back. It is whether the restarted instance can distinguish an existing position, pending order or prior decision from a new one. The same discipline supports a cBot restart test and complements a symbol checklist before a cBot trades.
Review the log in a fixed order
A post-trade review becomes shorter when its questions are always asked in the same sequence:
- Find the signal record and confirm the time, symbol and active run identifier.
- Read the guardrail records before the order record. A blocked trade may be correct behavior.
- Compare the request with the resulting order or position event.
- Mark anything that cannot be reconciled, including a platform event with no matching cBot record.
- Preserve the parameter snapshot used for that run before changing settings or code.
This workflow does not prove that a strategy has an edge, and a clean log does not make an automated system safe. It does something narrower and useful: it lets a trader test whether the system followed the rule it claims to follow.
Logging has limits that should stay visible
Logs can be incomplete, overwritten, badly timed or too vague to reconstruct a decision. A line written by the cBot records what that cBot chose to report; it does not independently prove that every external condition, platform state or execution detail was captured.
That is why the record should be reviewed beside the platform's own position and pending-order history, not instead of it. Retention, access and privacy also matter when logs contain account or trade identifiers. Define what the review needs and avoid collecting unrelated sensitive data by habit.
At realbacktesting, the same boundary matters for published research: a reproducible result is more useful than an assertion. Our proof page explains how to inspect the assumptions behind a cTrader-native backtest; an operational log answers a different question about what happened during a run.
Frequently asked
Is the cTrader Log tab enough for a cBot audit?
The Log tab can be a useful starting point because cTrader documents Print() output there. It is enough only if the cBot writes a consistent decision chain and the entries can be reconciled with platform events.
Should a cBot log every tick?
Not by default. A review log is stronger when it records decision-changing events and reason codes; indiscriminate tick logging can make the important sequence harder to find.
Does a clean decision log prove a cBot will be profitable?
No. A clean log can show that the reported workflow was followed. It does not establish an edge, forecast results or replace testing with realistic data and costs.
A cBot that cannot explain a decision has not made the decision reviewable. Record the chain before you need to defend it.