The first time a live run does something you didn’t expect, you’ll go looking for the logs. Whatever you didn’t capture before that moment, you can’t recover after it. So the time to decide what to log is before you go live, not during the incident.
Here’s the short, tactical list.
Orders, at every state, not just when they fill
Log the order when it’s submitted, when it’s acknowledged, when it fills (including partials), when it’s cancelled, and especially when it’s rejected. Rejections are the single most useful thing to capture and the most commonly dropped. Each entry needs a timestamp and an order ID, or you can’t reconstruct the sequence.
Fills, with prices and times
Every fill: its price, its quantity, the time it happened, and the order it belongs to. This is what lets you measure slippage later. Without fill prices, you’re flying blind on execution quality.
The decision and what triggered it
When the strategy acts, log why, the event and the condition that fired. When you’re staring at a strange trade three weeks from now, “it bought because the 20-bar crossed the 50-bar at 10:31” is worth an hour of guessing.
Anything that touches the broker boundary
Your assumed position vs. what the broker reports. Your advisory buying power vs. the broker’s behavior. Rejections that smell like state mismatches. The broker is the source of truth, and the moments your model and the broker disagree are exactly the moments you’ll want a record of.
Errors as structured records, not just stack traces
A stack trace in a log file is better than nothing, but a structured issue, with an identifier, a message, and a count, is what lets you see that the same problem happened forty times, not once. Separate “what went wrong” from the raw log detail.
The rule of thumb
Log what you’d need to reconstruct the run without being there: every order, every fill, every rejection, every decision, every disagreement with the broker. If you can replay the story from the logs alone, you logged enough. If you can’t, you’ll find out at the worst possible time.
The good news is this is exactly the kind of thing a platform should hand you by default, so that “what to log before going live” is a question you’ve already answered before you ask it.