Review alert status, firing history and notices

Open the rule whose behavior you are checking

Go to Alerts and identify the saved rule by name, instrument, metric and condition. Similar rules can use different sessions or thresholds, so the name alone may not be enough. Select Edit or the relevant row to make its evaluation context visible. The saved Enabled or Paused state describes your configuration, while the evaluator's current status describes whether usable observations are available. Read both before concluding that a rule is broken or that a missing popup means no server-side evaluation occurred.

Read Selected alert evaluation

The Selected alert evaluation panel shows Evaluation, Last value, Checked and Firings. Active means the evaluator has an eligible state; Waiting for data means it lacks a usable starting input; Input stale means the available input is no longer fresh enough. Paused reflects a saved pause. The Last value is an evaluation input rather than a promise that every chart elsewhere is at that same time. Use Checked to place the status in context, then Refresh status when you need an updated reading without editing the rule.

Use durable firing history

Open Alert firing history to inspect recorded firings, including their time, value, condition and threshold. This is the place to verify whether the server actually recorded an event. Compare the value with the condition as it was evaluated, and use the exact instrument and session when finding a related chart observation. A rule's later edited threshold should not be applied retroactively to an earlier firing. Retain the relevant history entry when reporting a discrepancy so support can investigate a concrete event rather than a general recollection.

1. Choose the saved rule and read its current evaluation panel.
2. Open Alert firing history and locate the relevant recorded time.
3. Compare the event's value, condition and threshold with matching market context.

Recognize the browser notice limits

The application shows a small queue of recent priority notices rather than a permanent stack of every event. Dismissing a notice clears that presentation; it does not delete the alert's recorded firing. A cold page refresh does not replay every historical inbox item as a brand-new popup. Priority colors help distinguish notices but do not alter the event's data quality. When verifying an event you missed while away, use firing history first instead of expecting a reopened browser to reproduce the exact popup sequence you would have seen live.

Separate inbox retention from feature history

The account notification inbox is a bounded recent view. Entries stop appearing after seven days, and only the retained recent pointers are presented. Alert firing history is separate, as are invoices and ticket conversations. An inbox item disappearing with age does not prove its owning alert was deleted or its history erased. Likewise, marking an inbox item read does not pause a rule. Use Alerts to change the saved rule and the relevant feature history to investigate its older outcomes, rather than using inbox state as a control panel for every feature.

Do not wait for routine alert email

Under the current policy, routine market alerts produce in-app history and inbox notices rather than email. Essential billing, account and security messages use their own allowed email paths, and customer-requested support replies are a separate explicit exception. Older saved immediate or digest preferences cannot enable routine alert email. If you received an account email successfully, that does not mean an alert should send to the same address. Distinguish the channel you are checking before opening a delivery investigation; otherwise a correctly inbox-only alert can look like missing mail.

Investigate the right layer

If firing history has an event but no popup was visible, report the browser, whether the page was freshly opened or already running, and whether you had dismissed or queued other notices. If history has no event, inspect input freshness, baseline, session, cooldown and enabled state instead. If the status itself cannot load, preserve the safe service error rather than treating an old retained value as current. Pause or resume the rule through its saved row when needed, and verify the result before using later observations to assess its behavior.