Create a server-side market alert

Start with the observation you need

An alert saves a server-evaluated condition for a specific instrument and supported metric. Decide whether you want a current level to be satisfied or a movement across a threshold before choosing the condition. A price alert and an unusual-print alert test different kinds of observations, so a number that is meaningful for one may be meaningless for the other. Alerts do not place orders. They record eligible market conditions and create in-app notices under the account's current access and active-alert limits.

Open the condition form

Open Alerts and choose New. Give the condition a name that will be understandable in its saved row and firing history, such as a symbol, metric and intended threshold direction. Select the exact instrument rather than relying on whichever chart happens to be open elsewhere. For an option-specific workflow, the exact contract includes its root, expiration, strike and call or put right. A broad underlying-family condition is a different target. Review the instrument again after choosing the metric because supported inputs depend on the selected target.

Choose metric, condition and threshold

Use a metric offered by the form for that instrument. Above and Below test a satisfied level, while crossing conditions need eligible observations on the appropriate sides. Enter the threshold in the metric's unit: a price, premium or size value has a different interpretation. For example, an Above price threshold asks whether the fresh value satisfies that level; it does not require that the chart visibly traded through it after you opened the page. A crossing rule deliberately requires a baseline and subsequent observed movement.

1. Select the intended instrument and supported metric.
2. Choose the condition that matches level or crossing behavior.
3. Enter the threshold and verify its unit against the chosen metric.

Set session, cooldown and priority

Choose the session whose observations may satisfy the rule. Regular-session permissions do not automatically include GTH, Combined or curb inputs. Cooldown is entered in seconds and bounds repeat firings; it does not repair missing observations or authorize a different session. Priority changes the browser notice presentation, with 1 green, 2 yellow and 3 red. Use a higher priority to express urgency in your own workflow rather than expecting different provider freshness or a bypass of the saved cooldown. Review all three controls together before saving.

Save enabled or paused and check evaluation

Save the condition and inspect the saved row. An enabled rule is evaluated on the server, so leaving the Alerts page or closing the browser does not disable it. A paused rule remains saved without active evaluation. Select the rule to read Selected alert evaluation, including Evaluation, Last value, Checked and Firings, and use Refresh status when needed. Waiting for data and Input stale mean a usable current observation is missing; an Enabled label alone is not proof that a source is currently eligible.

Verify the recorded result

When an eligible condition fires, inspect Alert firing history for the actual recorded time, value, condition and threshold. Firing history and the in-app inbox are saved together. A browser popup is a bounded presentation of recent events, so missing or dismissing that popup is not the same as losing the durable firing record. Routine market alerts are inbox-only under the current email policy. Do not rely on receiving an alert email simply because essential account emails or support reply emails work for the same address.

Troubleshoot an alert that stays quiet

Check the exact instrument and metric, enabled state, selected session, threshold and latest evaluation status before editing several controls. A new crossing rule seeds from its current eligible observation rather than replaying pre-creation history. Stale data, a feed gap or changed evaluation inputs can reset the crossing baseline. A historical chart or replay frame cannot satisfy a live alert. If the rule still behaves unexpectedly, include its name, safe settings, evaluation state and relevant firing-history entry in a ticket, without claiming that a chart image alone proves an eligible live crossing occurred.