Start with the physical path. You draw a level on a 15-minute chart. The platform's server evaluates that condition on incoming ticks or on bar closes. When it triggers, it emits a message. That message goes to whichever channels you configured: an email server, a mobile push gateway, a browser notification, an SMS carrier, or an HTTP endpoint you control. Each of those has its own queue and its own failure mode.
The distinction that matters most is between an alert evaluated on the vendor's servers and one evaluated in a client application on your machine. A server-side alert keeps working when your laptop lid is shut. A terminal-side alert, the kind most desktop platforms offer natively, dies with the terminal. Traders discover this the first time they close the lid on a running setup.
The four routes and what each costs you
Push notification to a mobile app is the fastest common route and the one that gets ignored fastest, because it looks identical to every other notification on the phone. Email is reliable and slow, and it is the only route that gives you a searchable archive without extra work. SMS is expensive per message and survives bad data connections. A webhook, an HTTP POST to a URL you own, is the slowest to set up and the only one you can build logic on top of.
Most working setups use two: a push for immediate attention and a webhook for anything that has to be recorded or forwarded. Sending the same alert down all four channels feels thorough for about a week, then it becomes the reason you stop reading any of them. That failure is common enough to have its own treatment in alert fatigue management.
Where the delay actually comes from
Traders usually assume the platform is the slow part. Sometimes it is, but the larger delays sit downstream. Mobile push services batch and defer messages to save battery, particularly when a phone has been idle. Email providers apply greylisting to unknown senders. A webhook receiver that runs on a cheap shared host can queue behind other requests. If your alert triggers a trade decision on a five-minute chart, a 20-second delay is survivable. On a one-minute chart it is not, and you should say so before you build the chain rather than after.
There is also a decision inside the alert itself: does it fire on the first tick that touches the level, or on the close of the bar? Tick-based alerts fire earlier and produce more false triggers on wicks. Close-based alerts are quieter and later. This is the same choice traders make when reading candle close times, and it should be made per strategy, not once globally.
Test the whole chain with a deliberately easy condition before you rely on it. Set an alert that must fire within a minute, then confirm it arrived on every device you intend to use. A chain that has never been tested end to end is not a chain.
Building a chain that carries information, not just noise
An alert that says "EURUSD alert" is close to useless by the time you read it. The message body should carry the instrument, the timeframe, the level, the direction and the current price. Most alert engines support placeholders in the message text for exactly this. On TradingView, alert message templates and webhook payloads can include the ticker, the interval, the close and any plotted series value from the script, which means the alert arrives as a small structured record rather than a nudge.
Once the payload is structured, routing becomes a decision you can automate. A small receiver can read the JSON, decide whether the alert matters at that hour, and forward it to Telegram for a signal you want to see immediately, or write it to a spreadsheet for one you only want in the weekly review. That is the same architecture that Telegram signal channels use, just pointed at one person instead of a subscriber list.
- Give every alert a name you can search later, such as "XAU H1 supply retest", not "alert 3".
- Route by urgency, not by instrument: things you might act on within minutes go to push, everything else goes to a log.
- Include the trigger price in the message so you can compare it against the price when you actually read it.
- Set an expiry on alerts tied to a level you no longer trade, or delete them on the same day you close the idea.
- Keep one alert that fires daily at a fixed time as a heartbeat, so silence tells you the chain broke.
The heartbeat point is the one most people skip. A routing chain fails silently by definition: nothing arrives, and nothing arriving looks exactly like a quiet market. A daily test message removes the ambiguity for the cost of one notification.
Where alerts stop and orders begin
The natural next step after routing is execution: if the webhook can reach a server, the server can place an order. That crossing deserves more caution than it usually gets. An alert that misfires costs you a glance at your phone. An order that misfires costs money and can keep costing it while you sleep. If you go that way, the receiver needs position limits, a kill switch and a record of every message it acted on, which is the same discipline described in expert advisors and the same reason serious automated setups run on a dedicated VPS rather than a home connection.
For most discretionary traders the honest answer is that alerts should stay alerts. The value of routing is that it lets you leave the screen, which is the single largest improvement available to anyone who trades higher timeframes and currently watches charts because they are afraid of missing the entry. Chart-side alerts and cross-device delivery are built into modern web platforms including eTrader, so the setup cost is configuration rather than engineering.
One practical closing point on hygiene: review your alert list monthly and delete anything you cannot immediately explain. A list of forty stale alerts guarantees that the two live ones arrive in a crowd.
"If you cannot say out loud which link in the chain fired last, you do not have an alert system. You have a habit of looking at your phone."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- Server-side alerts keep running when your machine is off; terminal-side alerts do not.
- Most delay sits downstream of the platform, in push batching, email filtering or a slow webhook receiver.
- Put the instrument, timeframe, level and trigger price in the message body so the alert is usable on arrival.
- Run a daily heartbeat alert, because a broken routing chain and a quiet market look identical.
Frequently Asked Questions
What is the fastest way to get a chart alert to my phone?
A server-side alert sent as a mobile push notification is normally the quickest common route. Delivery still depends on the push service, which batches messages when a phone has been idle, so treat it as seconds rather than instant.
Should alerts fire on tick or on bar close?
Tick-based alerts fire earlier and produce more false triggers on wicks. Close-based alerts are later and quieter. Match the choice to the strategy: intraday breakout work usually wants ticks, structural levels usually want closes.
Are webhook alerts worth setting up for a discretionary trader?
They are worth it if you want alerts recorded, filtered by time of day, or forwarded into a channel you already read. If you only need a nudge on your phone, a plain push alert does the same job with far less to maintain.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.