In one of Algoyar\u2019s custom projects, the client needed to run a trading strategy on TradingView\u2019s second-based timeframes<\/strong> and send its trading signals to MetaTrader<\/strong> in real time.<\/p>\n The main challenge was the high number of signals generated by the strategy and TradingView\u2019s limit on the number of alerts that can be sent within a specific time period (up to 15 alerts in 3 minutes<\/strong>). 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<\/strong> to MetaTrader immediately and independently.<\/p>\n 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.<\/p>\n When a strategy generates a large number of trading events, TradingView\u2019s alert limit can become a serious challenge for automated trading systems.<\/p>\n 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.<\/p>\n 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.<\/p>\n The main challenge was therefore:<\/p>\n How can a large number of trading events be sent continuously and reliably to an external system despite TradingView\u2019s alert limitations?<\/strong><\/p><\/blockquote>\n To address this challenge, instead of relying on a single Alert, a multi-alert management system<\/strong> was developed as part of the strategy.<\/p>\n The system used multiple alerts running simultaneously, while dynamically managing which alert should be used to send each message.<\/p>\n 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.<\/p>\n To achieve this, the conditions and information related to alert delivery were stored and managed using a dedicated data structure.<\/p>\n 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.<\/p>\n The basic workflow can be illustrated as:<\/p>\n Trading Event \u2192 Check Recent Alerts \u2192 Select Available Channel \u2192 Send Message \u2192 Record New Alert<\/strong><\/p>\n This allowed the system to distribute the message load across multiple alerts instead of sending every message through a single alert.<\/p>\n One of the key parts of the project was developing the logic for monitoring and managing alert usage.<\/p>\n Before sending each new message, the system first checked the status of recently used alerts.<\/p>\n 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.<\/p>\n As the number of messages increased, the system would automatically switch to the next available alert.<\/p>\n 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.<\/p>\n The entire process was handled automatically without requiring any manual intervention from the user.<\/p>\n Since the project was not limited to sending entry signals, the system was designed to handle different types of trading events.<\/p>\n For example:<\/p>\n 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.<\/p>\n 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\u2019s status in TradingView.<\/p>\n Another important part of the project was establishing communication between the strategy execution environment and MetaTrader.<\/p>\n 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.<\/p>\n In this architecture, TradingView acted as the signal-generation engine<\/strong>, while MetaTrader served as the trade execution environment<\/strong>.<\/p>\n This allowed the strategy to run in TradingView while the actual trades were executed through MetaTrader.<\/p>\n 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.<\/p>\n The key results of the project included:<\/p>\n Multi-Alert Management<\/strong> Real-Time Alert Monitoring<\/strong> Support for Different Trading Events<\/strong> TradingView\u2013MetaTrader Communication<\/strong> Suitable for High-Frequency Strategies<\/strong> Protection of the Client\u2019s Trading Logic<\/strong> This project is a good example of the types of challenges that can arise in automated trading systems beyond simply implementing the strategy itself.<\/p>\n Platform limitations, data transmission, message management, and communication between different trading environments can sometimes become independent technical challenges that require their own solutions.<\/p>\n In this project, a smart alert management and distribution system<\/strong> 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.<\/p>\n For us, this project was a practical example of combining Pine Script, algorithm design, data management, and cross-platform communication<\/strong> to solve a real-world limitation in an automated trading system.<\/p>\n Note:<\/strong> To protect our clients\u2019 confidentiality, details about the strategy logic, entry and exit conditions, and proprietary trading structure are not disclosed in this case study.<\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":" This project focused on overcoming TradingView\u2019s 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.<\/p>\n","protected":false},"featured_media":12258,"comment_status":"open","ping_status":"closed","template":"","class_list":["post-12255","portfolio","type-portfolio","status-publish","has-post-thumbnail","hentry"],"_links":{"self":[{"href":"https:\/\/algoyar.com\/en\/wp-json\/wp\/v2\/portfolio\/12255","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/algoyar.com\/en\/wp-json\/wp\/v2\/portfolio"}],"about":[{"href":"https:\/\/algoyar.com\/en\/wp-json\/wp\/v2\/types\/portfolio"}],"replies":[{"embeddable":true,"href":"https:\/\/algoyar.com\/en\/wp-json\/wp\/v2\/comments?post=12255"}],"version-history":[{"count":0,"href":"https:\/\/algoyar.com\/en\/wp-json\/wp\/v2\/portfolio\/12255\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/algoyar.com\/en\/wp-json\/wp\/v2\/media\/12258"}],"wp:attachment":[{"href":"https:\/\/algoyar.com\/en\/wp-json\/wp\/v2\/media?parent=12255"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The Challenge<\/h3>\n
\nThe Developed Solution<\/h2>\n
\nSmart Alert Capacity Management<\/h3>\n
\nHandling Different Trading Events<\/h2>\n
\n
\nTradingView\u2013MetaTrader Integration<\/h2>\n
\nProject Results<\/h2>\n
\nSmart use of multiple alerts to increase the overall message delivery capacity.<\/p>\n
\nTracking recently sent alerts and selecting the appropriate channel for each new message.<\/p>\n
\nHandling Entry, Exit, Partial Close, and other required strategy events.<\/p>\n
\nCreating a reliable communication path for transferring strategy signals to the trade execution environment.<\/p>\n
\nDesigned to handle situations where a large number of trading events can occur within very short periods.<\/p>\n
\nThe development focused on the signal delivery and alert management infrastructure. The client\u2019s proprietary strategy logic and trading conditions are not disclosed in this case study.<\/p>\n
\nConclusion<\/h3>\n