An alert that says "z-score greater than three" asks the operator to debug the alert before debugging the market.
By the time someone opens it, the spread may have narrowed, the book may have refilled, and the chart may look ordinary again. The live view answers what is true now. The alert needs to answer what was true when the system decided to interrupt someone.
That answer cannot be reconstructed reliably from a threshold alone.
A threshold is only a decision rule
Thresholds have a useful, narrow job. They tell the evaluator when a signal has crossed the point where it deserves attention. A z-score can say that a current value is far from a baseline. A percentage can say that a spread widened. A rate can say that cancellation pressure increased on one side of a book.
None of those facts explain the event by themselves.
Suppose an alert reports a z-score of 3.4. An operator still needs to know the observed value, the mean it was compared with, the standard deviation, the number of samples in the baseline, the window, and the signal definition. A z-score derived from a stable fifteen-minute baseline with thousands of observations carries different weight from the same score derived from a thin window during a reconnect.
The score is an output of a decision. The alert record needs the inputs and the decision context alongside it.
This matters most in live systems because the triggering state decays quickly. An hourly report can usually be regenerated from stored data. A live market condition may last for seconds. The operator arrives after the interesting part has gone away, often while the system is already making a new decision from a new set of observations.
An alert without context turns that delay into investigation work. The operator has to find the old chart, infer the baseline, guess which comparison was used, and decide whether the system saw a real market condition or a weak sample. The record should have carried that evidence forward.
The event has to preserve the market state
Price moves, spread widening, and cancel pressure are different alert families. They describe different market conditions and need different facts to explain them.
A price-move alert may need the current price, the previous value, the absolute and percentage move, the exchange, and the pair. A spread alert needs the spread, mid price, and enough detail to distinguish a liquidity problem from a change in the price level. Cancel-pressure alerts need the relevant book side, the cancelled amount, the total observed liquidity, and the period over which the ratio was measured.
The shared part of the record is still substantial. Each event needs its signal value, baseline mean, standard deviation, z-score, sample count, severity, window, baseline mode, and evaluation time. A cross-exchange event also needs the number of peers that contributed to its reference point. The explanation can then state the facts in language an operator can use without opening code or replaying the evaluator in their head.
Persisting these fields avoids a subtle failure mode. Recomputing an old alert from current history may produce a different answer because the baseline has advanced, a peer exchange has gone offline, or the source has corrected earlier data. The new calculation can be valid for the current state and still fail to describe the original event. An alert is an observation made at a point in time. It should retain the state of that observation.
The window carries part of the meaning
The same signal behaves differently across time horizons.
A five-minute price move catches abrupt movement. A sixty-minute window places the same movement in a longer trend. A fifteen-minute spread baseline may be a reasonable operational view of liquidity, while a five-minute baseline could be too sensitive to a brief burst of activity. The correct window depends on the question the alert is meant to answer.
That choice must be visible on the alert record. A label such as 15m gives an operator a stable statement to evaluate: this value was unusual against the previous fifteen minutes under the configured rule. If the window is inferred later from whatever the evaluator currently uses, an old event changes meaning when a rule changes.
Fixed windows also keep reports and dashboards honest. An operator comparing two alerts from different days needs to know whether they represent the same measurement. A durable window makes that comparison possible. It separates a change in market behavior from a change in how the system looks at the market.
The evaluator may evolve. Thresholds may be tuned. A later model may use more than a z-score. Those changes are normal. The event must preserve the version of the decision that actually happened rather than borrowing a newer rule at review time.
Baselines answer different operator questions
Baseline mode belongs in the same category as the window. It identifies the question the system was answering.
A pair-and-exchange baseline asks whether one stream is behaving unusually relative to its own recent history. That is useful when an exchange's price, spread, or cancel pattern changes sharply even if the rest of the market has moved in a similar direction.
A cross-exchange baseline asks whether one venue has diverged from its peers for the same pair. That is a different condition. It needs enough live peer venues to make the comparison meaningful, and it needs the peer count stored with the result. A result built from three available venues carries a different operational story from one built from ten.
The two modes can produce alerts for the same exchange at the same time. One could identify an unusual move in the market as a whole. The other could reveal that a single venue has stopped tracking the market. Collapsing them into one generic anomaly label removes the distinction that determines the next action.
An operator may check source health for the second case and broader market conditions for the first. The alert should make that path clear before they start looking through dashboards and logs.
Explanation is part of the data model
Teams often treat explanation as a presentation concern. The evaluator writes a score, and the frontend turns the score into something readable later.
That approach gives the browser responsibility for facts it does not own. The frontend can format stored values. It cannot recover a baseline that was never persisted, determine which peers were live at evaluation time, or infer why an alert was opened instead of skipped.
The event should carry an explanation generated from its own stored fields. For example, it can name the severity, family, pair, exchange, observed value, trailing window, baseline mean, standard deviation, sample count, and mode. A cross-exchange alert can include the peer count. A cancel-pressure alert can identify the affected side of the book.
That explanation serves several surfaces. A chart overlay can show a concise reason at the exact point where the event occurred. An alert drawer can expose the underlying measurements. A report can preserve the same language alongside the raw event. An acknowledgment or resolution workflow can attach an operator decision to a record that already explains itself.
The UI remains important, but it should render operational truth rather than manufacture it. If the API only returns a threshold breach, every client is forced to invent its own explanation. The first disagreement between those clients becomes an alerting bug.
Alert history is operational memory
An alert is a durable statement that the system observed a condition worth reviewing. Its lifecycle may later include acknowledgment, resolution, and comments, yet those actions should build on the original evidence instead of replacing it.
The original event answers what the evaluator saw. An acknowledgment can answer who reviewed it and when. A resolution can answer what the operator concluded. Keeping those facts separate makes the history useful during a later incident or data-quality review.
Notification delivery sits outside the core argument. A pager, email, or chat message can make someone aware of an alert. The durable record is what lets them understand it. Delivery gets attention to the right place. Explanation lets the operator decide what to do next.
Live systems generate more data than an operator can hold in memory. Alert records should compensate by preserving the exact evidence behind each interruption. That gives a team a way to inspect decisions after the market has moved, the screen has changed, and the original condition has disappeared.
The one-line version
Alerts are useful after the fact when they preserve the facts that made them fire.