Tradingview
Tradingview price alerts for crypto thresholds, timing and plan limits
Tradingview price alerts notify you when a selected crypto symbol reaches or moves beyond a specified price level. Your plan limits how many alerts you can keep active in each category. A plain price condition uses the price allowance; a drawing or indicator condition uses the technical allowance. Choose the exact market, crossing direction and notification settings before saving. Regular price alerts respond independently of the displayed chart interval. A drawing-based alert can wait for a candle close when you select Once per bar close.
A saved price condition connects a market level to a notification
A price alert monitors its saved symbol and condition, then records a trigger when the configured price relationship occurs. In the Create alert dialog, selecting Price makes the market price the input. The operator determines which movement qualifies, while the threshold supplies the level in that symbol's quote unit. Notifications deliver the matching event through the channels that you've enabled.
The alert name and message help distinguish similar rules in the Alert manager. Include the market and direction in the name when several levels belong to the same pair. A price notification reports a condition; an external execution system would need its own compatible integration to turn that message into an order.
Price and technical allowances constrain different alert conditions
The condition that you select determines which allowance the alert consumes, even when every rule concerns crypto prices. Price, technical and watchlist alerts have separate limits on the number of simultaneously active alerts. A Price condition on the main symbol with Crossing, Crossing up, Crossing down, Greater than or Less than uses the price category. Using an indicator, drawing, strategy or comparison-overlay symbol in the alert makes it technical. Channel and Moving operators also use technical capacity, including movement rules expressed as percentages.
A free technical slot won't replace a full price allowance. Subscription comparisons show the capacities available under each plan. Capacity counts active rules, while frequency controls how a rule can fire repeatedly. Multi-condition alerts trigger when all compatible conditions for the same symbol are met simultaneously and consume one technical alert slot. Their availability depends on the subscription. Keep a fixed threshold as a simple price condition when it expresses the intended event accurately; a moving line or calculated condition needs the corresponding technical rule.
The crypto symbol fixes the feed and quote unit
The selected symbol identifies the market whose price the alert watches, including its venue, pair and instrument type. An alert level belongs to that symbol's quote unit. Spot and perpetual futures symbols can refer to the same underlying crypto asset while following different market prices. Their tickers need enough context to distinguish those instruments.
A pair found through a crypto screener should retain its market identity when you create the alert. Comparing its notification with another venue's chart can create an apparent mismatch. A saved symbol's price history is the relevant comparison for that alert's threshold.
Crossing direction and minimum ticks define the triggering boundary
Crossing rules detect arrival at a level, while Greater than and Less than require a price beyond that level.
Arrival from either direction or a chosen direction
Crossing accepts a move to the threshold from either side. Crossing up requires movement from below; Crossing down requires movement from above. An upward-crossing rule won't fire simply because the price already sits above its threshold when you create it. The price must first move below that level and then return upward to it.
Strictly above or below the level
Greater than requires the price to exceed the threshold by at least the symbol's minimum tick. Less than requires it to fall below by that minimum increment. A tick is the smallest permitted price step for that symbol. These conditions express an above-level or below-level state, so their repeat setting deserves attention when the price remains on the qualifying side.
Can a standard price alert wait for a candle close?
A regular price alert can't require a candle close; use a compatible interval-dependent drawing or indicator condition for that purpose.
Price timing and drawing timing
Regular price alerts offer Only Once and Every Time, with triggers independent of the displayed chart interval. Every Time checks conditions each minute. A horizontal-line alert depends on an interval and offers Once per bar close. Select the condition as well as that frequency: an above-line closing requirement needs an appropriate above-level rule. Some non-standard chart setups, including Heikin Ashi and Range, also expose interval-dependent alert options. Sparse or late trades can delay a candle-close alert while the server waits for the next bar's first trade.
A touch that fades before the candle closes
The selected crypto pair, threshold L, chart interval and price path are hypothetical. Assume both relevant alert allowances have room and notifications remain enabled. The aim is to recognize a close above L. Use a horizontal-line alert at L with Greater than and Once per bar close, with an app notification.
Suppose the monitored feed registers a move from below L across that level, then the bar closes below it. A regular Price alert with Crossing up would record the upward crossing. The horizontal-line alert records no closing trigger. Its qualifying event would appear in the log after a bar finishes above the line by the required minimum tick. A matching app notification would demonstrate delivery of that event.
Notification channels and schedules govern message delivery
An alert needs enabled delivery channels and compatible device settings before its recorded trigger can reach your screen or inbox. App notifications require the mobile app signed into the same account and permission for push notifications. Browser notifications need browser permission. Email delivery uses the address configured for the account.
An alert can record a matching event while its notification schedule suppresses outbound messages. The schedule limits notifications, including webhooks, to permitted days and hours in your local account time zone. After changing your profile's time zone, restart the alert so the schedule uses the new local time. Crypto markets can continue trading outside those hours. The calendar indicator in the Alert manager exposes an alert's delivery window, so a silent event can reflect the chosen schedule.
For a single-use alert triggered outside its notification window, the platform records the muted event and keeps the alert active. It can notify when the condition next qualifies during permitted hours. That behavior doesn't promise delivery of every earlier muted event.
Stopped statuses and logs distinguish monitoring from delivery failures
The Alert manager's status explains whether a saved rule is active, manually stopped, triggered once or expired. Stopping a rule preserves its settings, while deletion removes the saved alert.
An expiration setting stops monitoring when its deadline arrives. Eligible subscriptions offer Open-ended alerts, which remove that scheduled deadline. Longstanding alerts that haven't triggered or been edited can still fall under inactivity deactivation rules. Keep the alert's actual status visible when deciding whether it continues to monitor the pair.
A missing log entry directs attention to the saved symbol, operator, threshold and active status. A recorded event with no received message points toward notification settings, the delivery schedule or the selected channel. The log gives the trigger history without requiring you to infer it from a phone notification.
For script-based technical alerts, changing the indicator's chart inputs doesn't update the existing server-side alert. Recreate it with the revised configuration when those inputs matter. A changed chart can otherwise display a condition that the saved alert isn't evaluating.
Watchlist monitoring and webhook delivery have different dependencies
Watchlist alerts apply a condition across symbols, while webhooks send an alert message to an external application.
A shared condition across a watchlist
Each watchlist alert evaluates its condition independently for the symbols in that list, subject to its separate subscription allowance. A common absolute threshold therefore applies in each symbol's own price units. Relative movement rules can express a different monitoring task, with their own interval-dependent conditions. Watchlist alerts don't support the Open-ended setting, so their expiration remains part of the configuration.
Message compatibility for an external application
A webhook sends an HTTP POST request containing the alert message. Valid JSON messages use the JSON content type; other messages use plain text. The receiving application must accept the format that you send. Webhook use requires two-factor authentication. Keep passwords and account login credentials out of the message.
Webhook delivery can fail even after an alert triggers. The receiver must respond within the service's timeout and use a supported network address and port. Delivery status appears in the alert log, while any downstream order needs confirmation from the execution system. Choose ordinary notifications when the task ends with reading a price event; add a webhook when a compatible external application needs that event.
Questions worth asking
-
How can I include the triggering crypto price in an alert message?
- The {{close}} placeholder inserts the bar's close value at the time the alert fires. Regular price alerts use one-minute bars regardless of the displayed chart interval. You can also include {{ticker}} and {{exchange}} to identify the saved market. {{timenow}} supplies the alert's firing time. These placeholders report alert data; the price in a message doesn't establish an executable quote or completed trade.
-
Where does the time zone in a crypto alert's log come from?
- The visible alert log uses your operating system's time zone. The chart's time zone setting doesn't change alert behavior or the displayed log time. An exported alert log uses UTC timestamps, so a spreadsheet can show a different clock time for the same event until you convert its time zone.
-
Does converting the chart's currency change an existing price alert?
- An existing alert continues to operate in the symbol's original currency after you convert the chart display. You can't create an alert on a currency-converted chart. The converted chart price and the saved alert threshold use different currencies; restore the original currency before configuring a new alert.
-
Will a plan upgrade remove expiration from alerts I've already saved?
- A subscription upgrade doesn't automatically replace an alert's saved expiration setting. If your new plan supports Open-ended alerts, select that option in the alert's expiration settings and save the change.
-
Can bar Replay test whether a crypto price alert sends a notification?
- Bar Replay doesn't drive server-side price alerts with the historical bars that it displays. Existing alerts continue to use real-time data, and you can't create new server-side alerts during replay. Replay can help inspect past price behavior, while notification delivery belongs to the alert's live monitoring and selected channels.
-
When does a watchlist alert begin monitoring a newly added crypto symbol?
- An active watchlist alert includes a crypto symbol when you add it to the watched list. Removing the symbol removes its coverage. An alert in a limited functionality state can stop calculations for affected symbols while continuing for others, so list membership alone doesn't establish that every member is receiving active monitoring.