Module 2 · Lesson 7 of 8 · Charting · About 5 minutes
Alerts as Reminders of Your Own Levels
On this page
Before you read: Drawing Tools: Lines, Zones and Keeping Charts Clean
What you will learn
- What a price alert on a charting platform does and does not do.
- Why an alert is a reminder to look, not an instruction to act.
- How alert fatigue, delays and failures affect alerts.
What does a chart alert do?
If price touches a line you drew, what actually happens?
An alert evaluates a declared condition and may produce a notification, such as a pop-up, sound, app message or email under the platform’s settings. In the ordinary reminder example here, it places no broker order. Some platforms also support configured webhooks: an alert can send a message to an external application, which may have separate order logic. That possibility does not make a notification a fill or guarantee delivery, broker acceptance or execution. Keep four events separate: condition true, message emitted/received, order accepted (if a separately authorized integration exists), and execution. No such integration is configured or authorized by this lesson.
Alert diagram
An alert is a reminder to look.
This ordinary reminder example places no order.
Illustrative diagram constructed for teaching. Not real market data.
Condition and message are distinct from an order or fill. The pictured ordinary reminder has no execution integration; other external workflows require their own configuration and authorization.
Why treat alerts as reminders?
Does an alert mean something important just happened?
An alert only means the condition you wrote was met. It knows nothing about news, liquidity or whether your reason for the level still holds. Writing a short note with each alert, such as “prior session high, check the plan”, turns it into a reminder to look at the chart and your plan. Alerts set by other people or sold as “signals” are a different thing and are not covered here.
What can go wrong with alerts?
Can an alert arrive late or not at all?
Notifications can be delayed by networks, devices or the platform. Alerts can expire, be limited in number by plan, or trigger on a brief spike that reverses at once. Too many alerts lead to alert fatigue, where notifications are ignored. Reviewing and deleting old alerts, and keeping only those tied to your written plan, keeps them useful. Exact alert options, limits and expiry rules vary by platform and plan.
Condition field, evaluation time and notification frequency are different settings. Completed fictional 09:00–09:05 CST bar: last price 100 at start, 101 at 09:02, and 100.50 at close. Level 100.75 was fixed beforehand.
| Declared condition/evaluation | Result on this path | Why |
|---|---|---|
| A: intrabar last-price crosses from ≤100.75 to >100.75 | True at 09:02. | 100→101 crosses; it may notify then if configured. |
| B: closed bar’s CLOSE>100.75, evaluated 09:05 | False. | 100.50 is below 100.75. |
| C: bar HIGH≥100.75, evaluated only at 09:05 | True at close. | The completed high is 101 even though close is lower. |
“Once per bar close” is not a synonym for “close price crossed”; C illustrates the difference. A notification limit such as once per bar does not by itself freeze all input values or fix an erroneous condition. A later view showing only the bar’s close does not prove an intrabar A message was false at its own timestamp. Record condition, field, frequency, bar status and observed message time. Server-held TradingView SCRIPT alerts use a creation-time snapshot; later chart/script changes do not automatically update that existing script alert. Other alert types must be checked under their own rules.
Delivery can be delayed or fail, and prices can change before review. An alert is not a promise of a particular execution price. Keep a short reminder note with each alert, and prune old alerts to limit alert fatigue.
What this does not tell you about alerts
- Which levels or conditions anyone should set.
- The exact alert options, limits or delivery methods on any platform.
- Whether an alert will arrive in time.
- Nothing here suggests any trade.
Method in Practice: alerts at the plan's levels
Fictional example. John, Harbor Index futures, the prices, times, costs and results are all invented for teaching. This shows how a written plan can be built and tested. It is not a recommendation, and nothing here says how often this idea works.
Try it on a real chart. Test this idea yourself on past sessions with bar replay. Keep your own count, including the days with no trade.
The idea. An alert is a reminder to look, not an instruction to act (this lesson). John sets alerts only at the levels his written plan uses. When one fires, he opens the plan before he looks at anything else. These are the Volume Profile Explained: POC, Value Area, HVN, LVN lesson's three replays, seen through his alerts.
John's alerts (set before 08:15 CT)
- Price crosses 101.20 (the prior value area low): "Check plan: count the 30-minute closes"
- Price crosses 102.40 (the value area high): "Check the second reference order"
- 12:00 CT: "Cutoff: no new setups after this"
Three outcomes
-
Worked: the 101.20 alert fired at 09:12. The plan said wait for two closes. Two came, and he traded → +$75
-
Fired, plan said no: the alert fired at 09:05 on a release morning. The plan's calendar rule said no trade → $0
-
Fired, no setup: the alert fired three times in Replay C. Each time the plan said one close wasn't enough → $0
Show the alert log
| Day | Alert | What John did | Plan line used | Result |
|---|---|---|---|---|
| Replay A | 101.20 crossed, 09:12 | Opened the plan, waited for closes. 09:30 and 10:00 both closed above | Entry condition | Bought at 101.55, +$75 |
| Release morning | 101.20 crossed, 09:05 | Opened the plan. Calendar: release at 10:00 | Not trading if | No trade |
| Replay C | 101.20 crossed, 09:08, 09:47, 10:40 | Each time: one close above at most | Entry condition | No trade |
| All days | 12:00 cutoff | Canceled any working idea | Not trading if | — |
Test it yourself
- List your alerts next to the plan line each one belongs to. Delete any alert without one.
- For a week, write down what you did each time an alert fired.
- Test whether alerts arrive in time on your platform and device. Don't assume they do.
Where it breaks
- Alerts can arrive late, or not at all.
- An alert going off can feel like a signal. It isn't one.
- Too many alerts and you stop reading them.
Reflection question: When your last alert fired, what did you look at first?
Check yourself
- Does the ordinary reminder example itself place an order? Does an optional webhook prove a fill? Hint: reminders versus broker orders.
- Why add a note to each alert? Hint: the reason for the level.
- What is alert fatigue? Hint: too many notifications.
- By 09:05, which of A/B/C was satisfied at its declared evaluation time under the stated path, and does once-at-close force use of close price?
Reflect on your own process
- For each alert you keep, which line of your written plan does its note point to?
- What does your process say to record when an alert fires: condition, field, frequency, bar status and the time you saw it?
- How often does your routine call for reviewing and deleting alerts, and who checks that it happened?
- When your last alert fired, what did you look at first?