Session windows for Topstep bots: when the bot should refuse to trade

When this topic matters

• Your discretionary edge is obviously time-of-day dependent, but your bot is not
• Overnight or lunch trades keep showing up as process mistakes
• You want automation to enforce boredom rules you will not enforce manually
• Replay quality changes dramatically by hour and you have been averaging that away
• Evaluation pressure tempts “trade anything with a pulse”

Why time filters belong in prop automation

• Many discretionary setups are session-bound even when traders pretend they are not
• Automation will cheerfully trade the wrong hour if you let it
• News windows and low-liquidity pockets can invalidate otherwise decent rules
• Prop daily budgets are finite; off-plan hours are an easy way to waste them

How to define a session window

Write it like an API contract:

1. Timezone basis (be explicit)
2. Start / end (inclusive rules)
3. Blackout windows (for example, planned major releases) if part of your plan
4. Behavior at boundary (flatten? cancel working entries? finish open trade only?)
5. Interaction with daily stand-downs
6. Logging when permission is denied due to clock

If timezone is implied “you know what I mean,” your bot does not.

Boundary behavior is half the design

Traders often define “trade 9:30–11:00” and forget the messy edges:

• What if entry signal prints at 10:59?
• What if a trade is open at window end?
• What if a protective order is working outside the window?
• What if reconnect happens after the window closed?

Write boundary policy before live. Ambiguity at edges becomes live drama.

Replay across sessions, not one favorite morning

Historical training should include days where your window was ugly. Botfolio’s replay-first messaging exists so you learn the setup’s personality before live privileges. Related: how to replay strategies in Botfolio and the existing train on historical data guide.

Segment review questions:

• Is the edge concentrated in the first hour?
• Does midday create slow bleed?
• Does the close deserve a hard blackout?
• Are “good” overnight outliers actually outside your competence?

Pair windows with supervision

A session window is not a babysitter replacement. Keep the command center open for live early sessions and know your emergency controls.

Clock filters reduce opportunity for mischief. They do not remove market risk inside the window.

Hypothetical example (not a result)

A failed-breakout ruleset works acceptably in a defined morning window during replay. The trader leaves the window unconstrained. The bot finds “perfectly valid” signals during thin overnight conditions that were never part of the research story. Nothing mystical happened — permission was too broad.

Narrowing the window does not guarantee profits. It aligns live permission with tested conditions.

Common failure modes

1. Window copied from someone else’s routine without replay proof
2. Blackouts abandoned on FOMC days because FOMO
3. Multiple strategies with conflicting windows and no portfolio-level permission policy
4. Timezone drift after travel / machine settings changes
5. Using windows as a substitute for a missing edge

Rule-design checklist

• Timezone documented
• Start/end rules unambiguous
• Blackouts listed with sources for why they exist
• Open-trade boundary policy written
• Interaction with day-loss stand-downs defined
• Replay segmented by hour/session
• Logging for clock-based denials
• Supervision plan inside the active window

What Botfolio does / does not claim

Does

• Emphasize session limits as part of account-discipline workflow
• Encourage defining session conditions as part of strategy rules
• Support supervised operation during live windows

Does not

• Auto-detect “best hours.” This guide does not claim automatic best-hours detection
• Guarantee that RTH-only or any other window is optimal
• Replace official platform rules

Field notes from supervised operators (composite, not testimonials)

These are composite lessons distilled from common prop-automation failure patterns — not customer quotes, not verified Botfolio case studies, and not performance claims:

• The bot that lacked a day-level stand-down did not fail dramatically; it failed by a thousand cuts.
• The operator who skipped flatten drills discovered that “I know where the button is” is not the same as using it under adrenaline.
• The strategy that looked robust until session windows were segmented was actually a one-hour idea wearing an all-day costume.
• The stage transition that reused old size settings turned a previously tolerable loser into an outsized budget event.

Use them as warning signs in your own review meetings.

Putting the education into a Botfolio-shaped operating cadence

Even when this article is mostly about trading process, the practical cadence still maps to Botfolio’s verified loop:

1. Encode the rule changes you just designed.
2. Replay before granting live-order privileges.
3. Promote only with account/sizing/risk settings explicit.
4. Supervise from the local command center with emergency actions reachable.
5. Demote back to replay when live behavior disagrees with the story you told yourself.

That cadence will not make a weak edge strong. It will keep weak process from impersonating a strategy.

Compliance reminder you should re-read often

Automation does not create a special exemption lane. If Topstep classifies a behavior as prohibited conduct or a prohibited strategy, doing it via software is still doing it — usually faster. Keep official help pages in your weekly ritual, especially around API access, prohibited conduct, prohibited strategies, and responsible trading. This site’s older checklist post remains useful as a prompt, not as a substitute for primary sources: Topstep automated trading rules checklist.

Building a session policy you can defend in a review

A session window is only as good as the story behind it. “I trade mornings” is not a policy. A defendable policy sounds more like:

• The setup depends on opening auction effects and early directional discovery.
• Replay shows midday mean-reversion chop destroying the continuation logic.
• Overnight was never part of research competence, so permission is denied by default.
• Major scheduled risk events are blacked out because the strategy has no news model.

Write that story in your notes. When impatience arrives, you will need it.

Multi-strategy permission (conceptual)

If you eventually supervise more than one ruleset, conflicting windows become an ops problem. Portfolio-level questions:

• Can two strategies be active in the same minute?
• Is there a shared day-loss stand-down across strategies?
• Who wins if one strategy wants lunch and another wants the close?

Botfolio marketing references bots in the plural and a dashboard supervision model, This guide does not state a multi-bot concurrency limit. Prefer simplicity until you confirm what your installed build allows: fewer live permissions, clearer diagnosis.

Worked clock example (hypothetical)

Policy draft:

• Timezone: America/New_York (example only — use yours explicitly)
• Window: 09:35–11:15 for new entries
• Blackout: predetermined high-impact release windows you personally refuse
• Open trade at 11:14: allowed to manage via existing exit rules, no new entries after 11:15
• Reconnect after 11:15: strategy may not re-arm until next session

Then replay with that policy fixed. If you keep editing the window until the past looks pretty, you are curve-fitting a clock.

Session windows and prop psychology

Evaluation anxiety loves off-plan hours because they feel like “extra chances.” Funded overconfidence loves them because they feel like “I can handle it.” The window’s job is to be boring enough to survive both moods.

Pair this with stand-down rules so a bad morning inside the window still ends correctly.

Quick takeaways

• Not necessarily. Trade the hours your edge was tested for. If you did not test overnight, do not automate overnight.
• No. Platform rules and prohibited conduct still apply inside any window.
• Do not assume that. Public messaging emphasizes you defining session/setup rules and replaying them. Confirm any smarter scheduling features in-app if they exist for your version.
• Then prove it in replay with honest segmentation.