High-of-day momentum scanner: a new high is an event, not a thesis.

Define what “high of day” means in the system

A high-of-day event is straightforward: price exceeds the session’s prior high. The scanner design problem is not the event definition—it is deciding which symbols are eligible to trigger the alert.

Filter before the event

Use objective constraints such as price, liquidity, minimum activity, relative volume, gap/context, or a prebuilt watchlist to keep the event stream relevant. The more universal the alert, the more likely it becomes background noise.

Separate momentum confirmation from chase behavior

A new high can indicate strength, but the alert itself says nothing about whether the move is extended, liquid, or likely to continue. Treat it as a prompt to re-evaluate the candidate against your plan, not as an automatic entry instruction.

Use a ranked list to decide what deserves an alert

One efficient pattern is to use a Top List or screener to identify a small set of strong/active symbols, then apply a high-of-day event alert to that narrower universe. This separates “who is interesting?” from “when should I look again?”

Measure alert quality in paper mode

Track alerts per hour, percentage that occur after obvious extension, average spread/liquidity at trigger time, and how often you can evaluate the symbol before the move changes. These operational metrics reveal whether the scanner improves decision-making even before any profitability analysis.

Control alert fatigue before adding more filters

If a high-of-day alert fires too often, first narrow the eligible universe rather than stacking arbitrary confirmation rules after the trigger. Restrict the scan to the price/liquidity range you actually trade, a premarket or opening watchlist, or symbols meeting a participation condition. Then measure whether the number of alerts per hour becomes operationally manageable.

Alert fatigue is a real workflow defect: when every beep looks equally important, the scanner stops directing attention. A smaller event stream also makes post-session review more meaningful because each alert can be classified rather than ignored.