Alert

Standalone Security Alerts

Standalone alerts are created directly on a security in a watchlist without requiring a rule-based strategy. Via the context menu of a security in the watchlist choose Add alert…, whereupon the Strategy definition dialog opens. GT creates the corresponding Strategy security entry, which links the security with its alerts, by itself; if you cancel the dialog without entering a strategy, nothing is left behind. These alerts are evaluated independently of a rule-based strategy and are suitable for simple monitoring of individual securities.

Alerts Within a Rule-based Strategy

Within a Portfolio based strategy, strategies can be assigned on the levels portfolio based strategy, asset class and security, see Rule based trading. When the condition of such a strategy is met, the system generates an alert as well. A strategy on the portfolio based strategy is evaluated for the securities of its watchlist, a strategy on an asset class for the securities of that asset class. Evaluation respects the activation on every level involved: if a higher level is deactivated, the alerts below it rest too. You switch the portfolio based strategy in its tree table with Activate or Deactivate, a security and its strategies with the Active checkbox of the alert overview; asset classes have no switch of their own. A portfolio rebalance on the portfolio strategy delivers its recommendations as messages as well; when these arise is described under Portfolio Rebalancing.

Alert Types

Six alert types are available for securities. The letters in brackets after a field name are the short designations used in GT.

The same alert type may be entered more than once on a security, for example two absolute price bounds with different values. Only the portfolio rebalancing and the Mean Reversion Dip are limited to one per level.

Alert Overview

The overview of all alerts of a tenant is reached through the client in the navigation tree and there through the tab Alert. It is built as a tree table: the top level holds the security with its currency, below it as child nodes the alerts entered, with their alert type in the column Strategy name. The column Context shows with Standalone or Part of strategy whether the alert stands on its own or belongs to a rule-based strategy.

The column Active contains a checkbox, on the row of the security as well as on the row of a single alert. A change is saved immediately. An alert or a whole security can thus be suspended temporarily without losing its configuration.

Through the context menu of the security row you enter a further alert with Create Strategy definition, or remove the security together with all its alerts with Delete Strategy security. If the security belongs to a portfolio based strategy, it thereby also disappears from its tree. On the row of an alert, Edit Strategy definition and Delete Strategy definition are available. When editing, only the parameters can be changed, not the alert type.

Alert Evaluation

All six security alert types are checked in the background. The administrator sets gt.algo.alarm.evaluation.interval.hours in the global settings to a whole number from 2 to 6 hours; the default is 4 hours. Changes take effect without restarting. A recent successful evaluation or background attempt postpones the next background attempt. New intraday observations can trigger an earlier evaluation. The scheduler checks for due work every five minutes, so evaluation can start up to five minutes later, plus any waiting time in the task queue. The actual work is done by background task 50. Ordinary securities are checked during their exchange’s opening hours, using the exchange’s time zone and recorded holidays. No automatic checks take place on weekends in that time zone. Crypto-classified securities are checked throughout the week. This exception applies to securities already supported by the alert system; it does not add alerts for cryptocurrency currency-pair entries. After the exchange closes and the data provider’s delay has elapsed, GT makes one final attempt if the closing observation has not already been evaluated. This attempt can occur sooner than the configured interval. A failed closing attempt is not repeated or caught up over the weekend. GT reuses a sufficiently recent quote from the current trading session or requests a new one. Several alerts for the same security share the downloaded quote. If the quote remains too old, or required history or exchange information is missing, no alarm is generated. GT records the reason and preserves the previous valid crossing observation. A failed background attempt waits for the configured interval before another attempt. Price, moving-average and RSI crossings need a valid starting observation first. The first valid observation establishes it and raises no alert yet. Editing or reactivating an alert establishes a new starting observation, so that a period of deactivation cannot create an apparent crossing. A movement across a threshold and back between two observations can remain undetected. The following flow shows the path from the due check to the message.

flowchart TD
    S([Every five minutes: check for due alerts]) --> D{Alert due?}
    D -->|No| W[Wait until the next interval]
    D -->|Yes| B{Exchange open or cryptocurrency?}
    B -->|No| W
    B -->|Yes| Q[Obtain the quote once per security]
    Q --> F{Quote recent enough and data complete?}
    F -->|No| R[Record the reason, keep the comparison value, no alert]
    F -->|Yes| E{Condition met?}
    E -->|No| W
    E -->|Yes| A{Already reported today?}
    A -->|Yes| N[No second message]
    A -->|No| M[Record the alert and deliver it as a GT message]

Alert Lifecycle

When an alert condition is met, the system records the alert with the details of the triggered condition. The user is then notified via GT’s internal messaging system, in the language of the client. The subject names the context of the alert, the message body the security and the details of the trigger. The user can read the message, assess the situation and then independently decide on the desired action. GT does not execute automatic transactions. If a message could not be delivered, it is sent again later from the recorded alert, without the alert being raised a second time.

Deduplication

So that the same situation is not reported repeatedly, GT distinguishes an alert by client, alert, security, kind of signal, direction and day. Repeated evaluations of the same signal on the same day therefore result in a single message. Two securities never suppress one another, and a crossing upwards and one downwards on the same day are two separate messages.

Limitations

The alert type of an existing alert can no longer be changed; instead a new alert is entered and the old one deleted. Currency pairs of a watchlist cannot carry an alert, alerts are reserved for securities. Besides the background schedule described above, Evaluate now in Alert diagnostics starts an immediate evaluation of your own alerts; the button Alert diagnostics sits above the alert overview. In the tabs Evaluation, Trading decisions and Notifications the diagnostics show the latest evaluations, the decisions of the Mean Reversion Dip and the state of delivery; Retry selected notification sends an undelivered message again. The number of portfolio based strategies, asset classes, securities and strategies per client is bounded by the limits of the information classes. If the installation has switched the alert function off, the tab Alert and the entry Add alert… in the watchlist are missing.