How to Design Price and Indicator Alerts: Closed Bars and Alert Fatigue

What an alert does and does not do

Nobody can watch a live chart all day, so many people rely on alerts that sound or flash when a preset condition is met. An alert does exactly one thing: it reports that a condition you set has just been satisfied. It does not tell you whether that condition matters or what to do now. Defining an alert as "a reason to open the chart" rather than "a signal to act" makes design much easier. When an alert fires, the job is to check the chart in a prepared order, and doing nothing as a result is a perfectly normal outcome. Without this distinction, every alert becomes pressure to decide, and each one makes you hurry. Used only as a prompt to check, alerts can be set a little wider without much burden. This article covers which bar to base price and indicator alerts on, how to cut down repeated alerts, and how the alerts in this site's tools actually behave.

Definition: the three parts of an alert condition

An alert condition can be written in three parts: what to watch, what event triggers it, and which bar's values decide it. A price alert uses a single price, as in "if the current price crosses this level," while an indicator alert uses a calculated value, as in "if RSI rises above 70" or "if the close moves above the moving average." Many people set the first two parts and leave the third blank, yet the same condition fires at very different times and frequencies depending on whether it is judged on the forming bar or the closed bar. The word "crosses" can also be read two ways: a touch method that alerts as soon as price reaches the level, and a close method that alerts only when a bar closes beyond it. Filling in every item below makes it easy to trace later why an alert fired or why it did not.

• Target: the instrument and bar length (e.g. Bitcoin 1-hour, Samsung Electronics daily)
• Condition: a price level, an indicator value, or a cross between lines
• Method: alert on a single touch, or only on a close beyond the level
• Reference bar: the forming bar or the bar that just closed
• Repeat rule: when to alert again if the same condition is met again

Closed bars versus the forming bar

Most indicators are calculated from closes, and the close of a forming bar is just the current price, not yet settled. An indicator alert judged on the forming bar can therefore fire before the bar ends, only for the condition to have vanished by the close. If 1-hour RSI briefly rises above 70 and closes at 68, a forming-bar alert has fired, yet the chart keeps no bar above 70. A closed-bar alert judges once after the bar ends, so what fired matches what the chart records later. The price is a delay of one bar, which can mean up to a full day on a daily chart. A common setup is to keep decision alerts on closed bars and add a separate price-touch alert for things you need to know quickly. A touch alert near a support level, for example, makes sure you open the chart in time, while the actual judgment waits for where that bar closes. As the article on false breakouts showed, crossing a line intrabar and coming back is not unusual.

Alerts that flicker at a boundary: buffers and re-alert intervals

When price hovers right at a level, "crossed" and "came back" can alternate every few seconds and the alert keeps firing. Two methods are widely used against this. The first is a buffer: alert immediately when the level is crossed, but count a return only after price has moved back past the level by a set margin. Separating the crossing level from the return level means a wobble at the boundary fires only once. The second is a re-alert interval: once an alert fires for an instrument in one direction, the same alert stays quiet for a set time. Both have costs. A wider buffer catches real reversals later, and a longer interval can stay silent through a large move. Some designs add an exception that alerts again within the interval if price moves another full threshold beyond the first alert. It is also worth remembering that closed-bar alerts flicker much less from the start, because they judge only once per bar.

Alert fatigue: more alerts, less attention

When people first set up alerts, fear of missing out leads them to use loose conditions on many instruments. But when alerts sound dozens of times a day, people soon learn to ignore them. This is well known from hospital alarms and server monitoring and is usually called alert fatigue. In the end, the one alert that truly matters gets buried among useless ones. The basic remedy is to write one line per alert stating what you will check when it fires. If no such line comes to mind, deleting that alert costs little. Another remedy is raising the bar length. Moving a 1-minute condition to 15-minute or 1-hour bars cuts how often a similar condition fires, and the alerts that remain point to larger moves. When watching many instruments, gathering matches into a list like a scanner and checking it at set times is less tiring than one alert per instrument. Logging a week of alerts and counting how many actually led you to open the chart makes it clear what to delete.

How alerts work in this site's tools

Some tools on this site have alert features, and the design choices above are built into each one differently. The behavior below was confirmed in each tool's code. What they share is that they all run inside the browser. No server watches on your behalf and pushes to your phone, so closing the page stops the alerts. Browsers may also slow timers in hidden tabs, so unless a tool is built to keep scanning in a hidden tab, as the volume spike scanner is, responses can lag while the tab is hidden. Alert settings are mostly saved only in that browser, so opening the tool on another device or browser means setting them again. Because each tool judges on different bars, check what an alert is based on before relying on it.

• Volume spike scanner: when a newly closed bar shows a spike above the chosen multiple, it alerts with a browser notification, the tab title and a short sound, and when enabled it keeps scanning while the tab is hidden
• RSI Radar: it logs when the current RSI, including the forming bar, crosses a threshold, and records the same coin in the same direction at most once a minute
• Coin ECG monitor: upper and lower KRW price alarms and an RSI 70/30 alarm are set separately for each coin and work only while the tab is open
• CoinRadar: it compares prices this page has received and alerts on coins that moved more than the threshold within the chosen window; the same direction is not repeated within the window unless price moves another full threshold
• Kimchi Premium Radar: it records once when a threshold is crossed and requires a 0.1 percentage point margin before counting a return

Common misconceptions

Because alerts feel like they run themselves once set, it is easy to skip checking them. These are misconceptions that come up often with alerts. Most come from not writing down the reference bar and the method.

• Treating an indicator alert that fired on a forming bar as a confirmed signal
• Thinking that an alert firing means you must do something now
• Assuming nothing happened because no alert fired (the page may have been closed or the connection dropped)
• Adding more and more conditions to avoid missing anything until every alert is ignored
• Treating an intrabar price-touch alert as the same thing as a close-based condition

How it looks different in crypto and stocks

Crypto trades around the clock, so alerts sound in the middle of the night too. For alerts that would fire while you sleep, raising the bar length or switching them off and reviewing the night's closed bars in the morning is less tiring. The daily close is just a time set by the exchange, so you need to match which exchange and which time a daily bar uses, or your judgment will not line up with other charts. Stocks move only during regular hours, so news from the closed period lands all at once as an opening gap the next day. A price-touch level is often jumped right past at the open, and the price in the alert can differ widely from where trading actually began. Large Korean stocks such as Samsung Electronics and SK hynix have a daily price limit, and US indexes and large tech stocks may move first in pre-market or after-hours trading, so which session's prices judge the alert is also worth checking. If the quotes are delayed, the alerts are delayed by the same amount.

Reading it on a live chart

When an alert brings you to a live chart, first check whether the last bar is still forming. If it is, its indicator values and line positions will keep changing until the close, so check whether the state the alert pointed to still holds and how long remains until the close. If the alert was based on the forming bar, the condition may already have cleared by the time the screen opens. That is better understood as the nature of forming-bar alerts than as the alert being wrong. If it was a closed-bar alert, the judgment is done, so watch whether the next bar continues or contradicts that result. Live connections can also drop. When a WebSocket reconnects, missed bars are fetched again and indicators recalculated, and in the process an alert can fire late or be skipped. If the screen shows a connection status, checking it before trusting an alert is a useful habit.

A practical checklist

When creating or cleaning up alerts, working through the order below leaves fewer gaps. Rather than trying to get everything right at once, it is more realistic to use them for about a week and then adjust based on the log.

• Write one line on what you will check when this alert fires
• Choose the instrument and bar length (smaller bars fire more often)
• Decide whether to judge on the forming bar or the closed bar
• Decide between the touch method and the close method
• Set a buffer and a re-alert interval to stop boundary flicker
• Check what the alert needs to work (whether the page must stay open, which browser stores it)
• After a week, compare alerts fired with alerts you actually checked, and prune

Limits and disclaimer

An alert only watches a condition for you; it does not tell you whether the condition is any good. Whether a condition meant anything in the past has to be checked separately, as described in the backtesting article, and even a checked condition is not guaranteed to work the same way in the future. Browser alerts can be missed in several ways: the page may need to stay open, operating system or browser settings may block notifications, and dropped connections cause delays. That is why important risk management should not rest on a single alert. The behavior of this site's tools described above was confirmed in the code as of this writing and may change when a tool is updated, so it is worth reading the notes on each tool's screen as well. This article explains how to design alerts; it does not recommend any instrument or condition and does not recommend any trade. Decisions made after an alert fires, and their results, are your own.