High-Frequency Alert Management

This project focused on overcoming TradingView’s alert limitations for a high-frequency trading strategy running on second-based timeframes. A smart multi-alert system was developed to manage and distribute a high volume of trading signals, including entries, exits, and partial closes, and deliver them reliably to MetaTrader in real time.

Handling High-Frequency Alerts in TradingView

Developing a Smart Alert Management and Distribution System for TradingView

In one of Algoyar’s custom projects, the client needed to run a trading strategy on TradingView’s second-based timeframes and send its trading signals to MetaTrader in real time.

The main challenge was the high number of signals generated by the strategy and TradingView’s limit on the number of alerts that can be sent within a specific time period (up to 15 alerts in 3 minutes). Due to the nature of the strategy, the system needed to send not only entry and exit signals, but also events such as Partial Close to MetaTrader immediately and independently.

As a result, relying on a single Alert was not enough for this project. Once the alert limit was reached, TradingView would stop sending further alerts, which could cause important trading signals to be missed.

The Challenge

When a strategy generates a large number of trading events, TradingView’s alert limit can become a serious challenge for automated trading systems.

This becomes even more important when working with second-based timeframes, where trading events can occur within very short intervals and a large number of signals may be generated within just a few minutes.

In this project, the system also had to handle more than just entry and exit signals. Different types of trading events needed to be delivered accurately and without missing any important messages.

The main challenge was therefore:

How can a large number of trading events be sent continuously and reliably to an external system despite TradingView’s alert limitations?


The Developed Solution

To address this challenge, instead of relying on a single Alert, a multi-alert management system was developed as part of the strategy.

The system used multiple alerts running simultaneously, while dynamically managing which alert should be used to send each message.

However, simply creating multiple alerts was not enough. TradingView applies its alert limit over a specific time window, so the system needed to keep track of how many alerts had recently been sent and select the appropriate alert for each new message.

To achieve this, the conditions and information related to alert delivery were stored and managed using a dedicated data structure.

For every new event, the system checked the recent alert history, calculated the number of alerts sent within the relevant time window, and selected the appropriate alert based on the remaining capacity.

The basic workflow can be illustrated as:

Trading Event → Check Recent Alerts → Select Available Channel → Send Message → Record New Alert

This allowed the system to distribute the message load across multiple alerts instead of sending every message through a single alert.


Smart Alert Capacity Management

One of the key parts of the project was developing the logic for monitoring and managing alert usage.

Before sending each new message, the system first checked the status of recently used alerts.

For example, if the number of messages sent within the relevant time window was still below the capacity of the first alert, the new message would be sent through that alert.

As the number of messages increased, the system would automatically switch to the next available alert.

This meant that once one alert reached its limit, the system could continue using the capacity of other alerts instead of stopping the delivery of trading signals.

The entire process was handled automatically without requiring any manual intervention from the user.


Handling Different Trading Events

Since the project was not limited to sending entry signals, the system was designed to handle different types of trading events.

For example:

  • Entry
  • Exit
  • Partial Close
  • Other strategy-specific events

Whenever an event was generated, it went through the alert management system. Based on the current alert usage, the system automatically selected the appropriate channel for sending the message.

This was particularly important because in an automated trading system, missing even a single message can cause the actual trading status in MetaTrader to become inconsistent with the strategy’s status in TradingView.


TradingView–MetaTrader Integration

Another important part of the project was establishing communication between the strategy execution environment and MetaTrader.

Signals generated by the strategy in TradingView were passed through the alert management system and sent as structured messages, allowing the receiving component in MetaTrader to process them.

In this architecture, TradingView acted as the signal-generation engine, while MetaTrader served as the trade execution environment.

This allowed the strategy to run in TradingView while the actual trades were executed through MetaTrader.


Project Results

By developing this system, the limitation associated with relying on a single alert was overcome, allowing the system to handle a much higher volume of trading events.

The key results of the project included:

Multi-Alert Management
Smart use of multiple alerts to increase the overall message delivery capacity.

Real-Time Alert Monitoring
Tracking recently sent alerts and selecting the appropriate channel for each new message.

Support for Different Trading Events
Handling Entry, Exit, Partial Close, and other required strategy events.

TradingView–MetaTrader Communication
Creating a reliable communication path for transferring strategy signals to the trade execution environment.

Suitable for High-Frequency Strategies
Designed to handle situations where a large number of trading events can occur within very short periods.

Protection of the Client’s Trading Logic
The development focused on the signal delivery and alert management infrastructure. The client’s proprietary strategy logic and trading conditions are not disclosed in this case study.


Conclusion

This project is a good example of the types of challenges that can arise in automated trading systems beyond simply implementing the strategy itself.

Platform limitations, data transmission, message management, and communication between different trading environments can sometimes become independent technical challenges that require their own solutions.

In this project, a smart alert management and distribution system was developed to coordinate multiple alerts and handle a high volume of signals from a strategy running on second-based timeframes, allowing those signals to be delivered to MetaTrader without relying on a single alert.

For us, this project was a practical example of combining Pine Script, algorithm design, data management, and cross-platform communication to solve a real-world limitation in an automated trading system.

Note: To protect our clients’ confidentiality, details about the strategy logic, entry and exit conditions, and proprietary trading structure are not disclosed in this case study.

Trade Management Panel
7
Hedge-Mode Simulation
8