Saturday Mornings I Read the Logs Before the News

For the last six months, before I open any news app, before I check the social feeds I curate, before I touch a single quote, I read my trading engine's scheduler log from the previous five trading days. Saturday mornings, with coffee, in order, top to bottom.

It takes about twenty minutes. The log is roughly 400 to 600 lines per week, and most of it is uneventful. APScheduler firing the right job at the right time. The engine connecting to Interactive Brokers, scanning the universe, returning empty. Monitor cycles running clean. The interesting part is what does not look like the rest.

This Saturday the interesting part was a single line:

2026-04-30 10:00:14 ET | options_monitor | WARN | Position SPY 30 APR 26 545 P held past DTE_FLOOR=2 (current DTE=1)

The DTE floor is supposed to force an exit on any short-dated position before it crosses below two days to expiration. The warning fired. The exit did not. I had missed it on the day because the position closed cleanly on its own twenty minutes later when the underlying ticked through the strike. The day looked fine in the P&L. The log did not.

If I had read the news first, I would have spent the morning thinking about Fed positioning, or whatever the lead headline was, and by the time I got around to logs the warning would have rolled off my mental list. By reading the log first, the warning was the first thing I saw. The trace took an hour. The fix was three lines in options_monitor.py.

What I look for

I do not read every line word by word. I read for shape. There are five specific things I scan for, in roughly this order:

1. Any line containing WARN or ERROR that did not also produce a Telegram alert. If it warned but did not alert, my alert thresholds may be tuned too loose.
2. Any scheduler job that took more than twice its usual wall-clock time. Slow-but-not-failed is the most common silent bug shape I have hit.
3. Any unexpected disconnect-and-reconnect pair on the IB connection. One a week is noise. Three is a real thing.
4. Any signal pass-through where the entry rule fired but no order was placed. There is usually a good reason, a risk gate caught it. If I cannot reconstruct the reason from the log, the log is missing context I need to add.
5. Any line that surprises me. Surprise is data.

The order matters. WARN and ERROR lines are easy to triage and resolve fast, so I do them first while my attention is freshest. The signal pass-through review takes longer because I sometimes have to load the actual market data from that bar to confirm the gate was right. I do that one last because by the time I reach it I have a clearer picture of what kind of week the engine had.

Why Saturday and not weeknights

I have tried doing this nightly. It does not work. During the week I am tired, the next morning is hours away, and I am triaging in a hurry. I either skim or skip. Two months of trying convinced me weeknight log reads were a habit I was performing, not a check I was actually doing.

Saturday morning is different. The market is not open. There is nothing to react to. I am reading not to fix today, but to prevent next week. The mental posture is wrong on weekday nights and right on Saturday morning. I have stopped fighting that.

The other reason is the news cycle. By Saturday morning the previous week is settled. I am not reading the log against a backdrop of what just moved. I am reading it as text. That separation, from the live tape, is what lets me notice the boring lines that turn out not to be boring.

The one rule I break the most

I have given myself a rule, and I break it often enough to know it matters: do not look at the P&L for the week before reading the log.

P&L colors the read. A green week makes you skim. A red week makes you fixate on the wrong lines. The log is more honest before you know which kind of week it was.

This Saturday, before I read the log, I knew it had been a quiet week. Three trades, two small winners, one breakeven. That framing made the DTE warning easy to dismiss as something that probably resolved itself, because the P&L said nothing was wrong. Which it had, and which it had. But not because the engine did the right thing. Because the underlying happened to cooperate.

If I had not seen the warning on the way past, I would have learned about that bug the next time SPY did not move into the strike before close. Which is to say after it had cost me money.

The general shape

A good log read works on the same principle as a good code review. The thing you are looking for is not the thing that screams. It is the thing that fits in. The line you almost skipped because it looked like the surrounding lines, but should not have. Pattern matching on the absence of expected variance is most of the skill.

This is also why I think the discipline survives me automating other parts of my stack. I could write a parser that flags every WARN line and emails me a digest. I have one, in fact, and it is useful. But the parser does not see the things I have not yet thought to look for. The Saturday read is where new categories of warning get invented, because I am the one noticing the surprise.

The log told me first. That is what I pay it twenty minutes for.