A green connection indicator tells you the bot reached the broker. It does not tell you whether the bot evaluated a candidate, attempted an order or received a fill.
The temptation is to loosen a filter until something happens. First find the last stage the bot actually reached.
This checklist uses concrete examples from the Trend Join Long package. If Claude or ChatGPT helped you build a different bot, use the same questions and locate the equivalent evidence in your own code.
1. Did the latest scheduled run do useful work?
Check the scheduled task's last-run time and result, then compare them with the bot's own records. A process can start successfully and exit early.
The package provides three useful diagnostic files:
| File | What to inspect |
|---|---|
logs/heartbeat.json |
Latest recorded timestamp and status. |
logs/cycle_runs.jsonl |
Stages grouped by a shared run ID. |
logs/cycle_errors.log |
Recorded unhandled exceptions. |
In PowerShell, from the package directory, these commands only read local files:
Get-Content .\logs\heartbeat.json
Get-Content .\logs\cycle_runs.jsonl -Tail 30
Get-Content .\logs\cycle_errors.log -Tail 30
A missing file is a clue, not automatically a failure: it may not have been created yet. Check the intended working directory and schedule.
Look for a recent run with stages such as connected, reconciled, managed and scanned. Some legitimate branches return before scanning. An end marker alone does not prove success: the cleanup path can write it after a failure. Match the run ID with exceptions, status and scheduler result.
If you see lock_busy, inspect the previous process. Do not delete its lock and start another trading cycle without knowing whether it is still active.
2. Was this an entry window?
A trading bot can be working correctly while refusing new positions.
The shipped rules set the ordinary entry window to 10:05–15:30 America/New_York. The cycle distinguishes off-hours, management-only periods and force-close behavior. It also consults IBKR calendar information for holidays and early closes; if calendar information is unavailable, the code can fall back to a regular close.
Read the actual status and configuration. Your computer's local clock is not necessarily the strategy's clock, and a normal weekday is not proof of a full trading session.
Do not expand entry hours simply because the bot is quiet.
3. Did it have usable inputs?
Next inspect the current watchlist and the data needed to evaluate its symbols.
Trend Join Long checks the watchlist's date. A stale list can produce a no_entries decision. Missing downloaded price data can produce entry_skipped with reason no yfinance data. The cycle also distinguishes delayed broker quotes and has branches that skip entries or position-management work when required data is unavailable.
That is different from “the strategy found no signal.”
Check the timestamp of the input you are using, not just the time the dashboard refreshed. A recent dashboard can display an older observation. Record which source supplied each value before asking an AI assistant to diagnose it.
4. What reason did the decision log record?
The package writes decisions to safety-check-log.json. Despite the filename, it is JSON Lines: one JSON object per line.
Get-Content .\safety-check-log.json -Tail 30
Possible evidence includes:
| Recorded event or reason | What it tells you |
|---|---|
entry_skipped: filters |
The evaluated candidate did not pass the implemented filters. Inspect the accompanying values. |
entry_skipped: already held |
Existing holdings excluded that symbol from new entries. |
| Daily entry cap reached | A configured limit blocked further entries. |
| Size too small | The sizing calculation did not produce an eligible quantity. |
entry_attempt |
The bot reached its order-attempt path; a fill is not yet established. |
entry_not_filled |
Inspect the returned result and broker records to distinguish the cause. |
These are code-defined examples, not results observed in your account.
The decision log is not a heartbeat. It only grows when a decision is recorded; an unchanged file cannot by itself tell you that the scheduler stopped.
5. Did the broker receive and fill an order?
If an attempt exists, compare the relevant broker order and execution records with the bot's result. Check quantities as well as status, including any partial fill.
IBKR's order-placement lesson explains order-status callbacks and filled/remaining quantities. A submitted order and a completed fill are different observations.
Before retrying, inspect working orders and positions. Re-running an order command just to see whether it works can create unintended exposure. Stopping the scheduler does not cancel broker orders or close positions.
Give Claude or ChatGPT a bounded diagnosis
Review this redacted run ID, stage trace, decision record and broker order status. Identify whether the last run stopped at scheduling, connection, input collection, a strategy/risk gate or execution. Explain the evidence and what is still unknown. Do not place orders, loosen filters, alter account mode or change risk limits.
A useful diagnosis might be “the watchlist is from yesterday” or “this candidate failed the volume filter.” Neither calls for rewriting the strategy.
Our free build guide explains the broader implementation and links to the optional source package. The main bot supports deliberately configured paper and live use; start diagnosis in paper where practical, and retain the account guards.