Skip to content

Watchlists & alerts · 4 min read

Use unusual-print and overnight alerts

Keep print thresholds, root coverage and session permissions explicit.

Choose a print event rather than a price level

An unusual-flow alert tests newly received actual executions for the selected underlying family. Executed premium and execution size describe the print; they are different from a price threshold, a cumulative chart curve or open interest. Start by deciding which print quantity you want to monitor. A large modeled exposure value is not a newly received large execution. The rule preserves exact contract and execution details when it fires, which lets you investigate the event without assuming every contract in the underlying family contributed to one observed print.

Set premium or size in the correct unit

Choose a supported unusual-flow metric for the intended underlying and enter its threshold. A premium threshold is an executed monetary amount, while a size threshold is the print quantity defined by the metric. Do not paste a contract price into a premium field and assume the same numerical value has the same meaning. Give the rule a name that includes its quantity and session, so later firing history is understandable. Check the supported metric list rather than inventing a condition based on an unrelated screener heading.

Save the intended session

Select the eligible session before enabling the rule. RTH, GTH, Combined and curb refer to actual market-session classification, not arbitrary display shading or your computer's local clock. Regular-session access cannot consume overnight observations just because a chart is visible after hours. The current account must have the relevant permission, the selected root must be eligible and the market calendar must classify the observation into the selected session. A closed or unsupported session should remain unavailable rather than being filled with a previous regular-session print.

  1. Choose the supported unusual premium or size metric for the underlying.
  2. Enter a threshold in that metric's unit and select an eligible session.
  3. Save the rule, then inspect its evaluation status and later firing details.

Understand the required source coverage

A subscription to an exact option's chart does not establish ticker-wide execution coverage for the underlying family. Unusual-print evaluation needs the eligible actual print stream for its target, with matching freshness and bulk trade coverage. A live quote in another market also cannot authorize it. When status says waiting, stale or unavailable, inspect the source and account session access rather than lowering the threshold to make a missing stream appear active. Lowering a threshold changes the question; it does not supply the observations needed to answer it.

Separate new executions from repaired history

Backfilled historical prints and cancelled trade conditions do not become new unusual-print alert events. This prevents a recovered history segment from looking like a fresh execution merely because it arrived during a later repair. A chart or tape can legitimately gain corrected historical rows without producing a new live alert for each row. When comparing an alert with the tape, use the original execution detail and timing rather than only the moment the row appeared on your screen. Captured history and live-event eligibility are related but distinct workflows.

Inspect the firing rather than inferring intent

Open Alert firing history and examine the exact contract, execution time, size or premium and threshold recorded for the event. A large print establishes an observed execution that met the saved condition; it does not establish the trader's full position, whether the trade opened or closed risk, or a guaranteed directional forecast. If you compare with an options-flow view, match root, session and filters. Different contract-family selections or a filtered tape can omit the qualifying event from the particular rows you happen to be viewing.

Troubleshoot overnight non-firings

Verify the account's overnight entitlement, the selected root's supported session, the current exchange-local trading date and the evaluator's freshness state. An overnight window can belong to the following trading date rather than the calendar date on your computer. Note whether the relevant print was newly received or later backfilled. For a support report, include the rule settings, status, exact contract and execution detail if available, and the time zone used in your report. Routine alerts remain inbox-only and never place orders, regardless of premium, priority or session choice.

More in Watchlists & alerts