Skip to content
Terminal

Updated

How to read a crypto alert receipt

An alert says a condition was met and names the price at that moment. A receipt is the later record: the price again, at times chosen in advance, from a named source. You can look up what the price did. The receipt is not a grade for the alert, and it is not a reason to buy, sell, or hold.

The four times

A useful receipt uses the same clocks for every alert.

The slots may disagree. The price can be higher an hour later and lower a day later. Each slot is a fact about its own time. Folding them into one score hides that disagreement.

Each filled slot needs the later price, the percent change from the price at the alert, the source, and the time. The percent is the later price minus the price at the alert, divided by the price at the alert. The sign stays. A lower later price is a negative percent. A higher later price is a positive percent. The arithmetic says which way the recorded price moved. It does not say either result was desirable.

A slot whose time has not arrived is empty. The label is that the price is not in yet, plus the time it will be checked. A zero in an empty slot looks like a flat market. The market was not measured. If the price feed did not answer, the slot says the price is unavailable. It does not borrow a number, and it does not reuse an older price without saying so.

One alert is one path

A single receipt is one path. The next fire can look different. The rule's record is the pile of receipts, not the latest one.

The median is defined by the NIST/SEMATECH e-Handbook, section 1.3.5.1. Sort the 24-hour percent changes. If the count is odd, the median is the middle value. If the count is even, the median is the average of the two middle values. In the handbook's terms, half the points are smaller and half are larger.

The mean is the sum of the changes divided by how many you have. NIST notes that extreme tails pull the mean. One very large percent, in either direction, moves the mean more than it moves the median. If you publish one number for what happened after 24 hours, the median is the more stable summary of the center. Publish the count beside it. A median over three alerts is a different object from a median over thirty.

Keep every completed receipt in the median, including moves against the direction of the alert. Dropping those rows describes a subset, not the rule.

A second line can count direction without turning the count into a prize. Of the alerts whose 24-hour price is in, how many were in the same direction as the move at the alert, and how many were the other way? Both counts stay. Neither count is a win. The receipt has no order, no size, and no fee. It is the later reference price that was stored.

What a receipt cannot say

It does not grade the alert. A level alert can be right about the cross and be followed by a price that goes anywhere.

It does not say what you would have made. The receipt has no order, no size, and no fee. Treating the percent as a return invents a trade that is not in the data.

It does not say what the next price will be. The median summarizes alerts that already happened. The next path is not in that list.

It does not rank coins or accounts. A table can count fires by rule type and show the median 24-hour change, with both directions included. Sorting coins or accounts by that median turns a record into a contest the data do not support. Alerts whose 24-hour price is not in yet stay in the fire count and stay out of the median. Say so, or the center looks more settled than it is.

A trigger log is not a receipt

A trigger list answers when the rule fired. A receipt answers what the price was at the times you said you would check. Several products keep the first record. The pages opened for this article do not show the second.

TradingView deletes log rows every day at 21:00 UTC if a trigger is older than 30 days, or if that alert has more than 100 triggers, keeping the latest 100. You can export a CSV first. Nothing on that page records the price 1 hour, 4 hours, 24 hours, or 7 days later.

Kraken Pro, last updated 20 January 2026, has Active and Historical lists and a Desktop log that can re-add a trigger. Robinhood Legend has an Activity tab for recent triggers. CoinGecko's auto-alert article and Cryptocurrency Alerting's FAQ describe the subscription or the message. None of those pages records the price afterward.

How to read the lines

Start with the price at the alert, the source, and the time. If either is missing, later percents have nothing firm to measure from. Leave a slot empty until its clock arrives. A 7-day slot on yesterday's alert is not due yet.

For the rule, read the fire count, how many receipts have a 24-hour price, and the median of those completed percents. One extreme print can move a mean. These lines record what happened. They do not tell you what to do with the coin.

Terminal stores the price at the alert and again at 1 hour, 4 hours, 24 hours, and 7 days, and it reports the median of the completed 24-hour changes with both directions left in.

FAQ

Why four times instead of one?

Each time answers a different question about the same alert. The 1-hour price and the 7-day price can point different ways. One blended score would hide that. The times are chosen before the path is known, so the horizon is not picked afterward.

Do later prices that went the other way stay in the median?

Yes. Those receipts stay in the count and in the median. Removing them makes the summary describe a subset. The median, as the NIST handbook defines it, describes the recorded percents. It is not a score you raise by deleting rows.

What if the later price is not in yet?

Leave the slot empty and show the time it will be checked. A zero would claim the price was unchanged. A copied earlier price would claim a measurement that did not happen. TradingView's alert log deletes triggers older than 30 days, or beyond the latest 100 for that alert, and the pages opened here do not add a later price at all.

Sources

Pages opened 2026-10-11 unless noted.

Start free