Forex-EA in MT4 überwachen: Kurse, Heartbeats und Alarme

Normalbetrieb festlegen, bevor Sie nach Fehlern suchen

Ein EA kann fehlerfrei arbeiten, ohne einen Trade zu eröffnen. Handelszeiten, Spread-Limits, ein bestehender Positionskorb, Risikoregeln oder ein fehlendes gültiges Signal können die Ruhe erklären. Die Überwachung soll prüfen, ob die vorgesehene Umgebung ihre dokumentierte Aufgabe erfüllen kann, einschließlich der Verwaltung bestehender Orders. Sie soll keine Mindestzahl an Trades verlangen.

Dokumentieren Sie Terminal, vorgesehenes Konto und Server, genaue Symbole und Zeitrahmen, EA-Version, freigegebene Inputs, Zuständigkeit für Orders und erwartete Betriebszeiten. Berücksichtigen Sie weitere Symbole, die der EA benötigt. Fragen Sie den Entwickler, welche Statusanzeigen, Protokolle und Verhaltensweisen nach einem Neustart tatsächlich verfügbar sind. Eine EX4-Datei liefert nicht automatisch einen Heartbeat oder eine vollständige Erklärung jeder Entscheidung.

Unterscheiden Sie drei Zustände: normal, bestätigtes Problem und unbekannt. Aktualisiert sich ein Dashboard nicht mehr, zeigen Sie den Zeitpunkt der letzten Beobachtung und kennzeichnen den aktuellen Zustand als unbekannt. Ein alter grüner Status ist kein aktueller Nachweis.

Vier Ebenen getrennt prüfen

Das sind getrennte Prüfungen. Sie lassen sich manuell oder mit einem gezielt eingerichteten Überwachungssystem auswerten. MT4 führt sie nicht automatisch zu dem hier beschriebenen Dashboard zusammen.

Eine Fünf-Minuten-Prüfung ohne Strategieänderung

1. Den tatsächlichen Betriebsort bestätigen. Prüfen Sie vorgesehenes Terminal und Konto, nicht einen lokalen Chart, der nach der Migration offen blieb.
2. Handelszeiten und benötigte Kurse prüfen. Klären Sie, ob jetzt Aktualisierungen zu erwarten sind und die genauen Broker-Symbole nutzbare Daten haben.
3. Initialisierung und Berechtigungen prüfen. Lesen Sie aktuelle Meldungen in Experts und Journal sowie den dokumentierten EA-Status.
4. Aktuelle Orders prüfen. Bestätigen Sie deren Verwaltung und den beim Broker tatsächlich vorhandenen Schutz.
5. Den Überwachungsweg prüfen. Kontrollieren Sie den letzten Bericht und den Empfang eines Testalarms auf dem vorgesehenen Gerät.

Fünf Minuten beschreiben ein Prüfungsformat, keine garantierte Diagnose und keine für jeden EA passende Reaktionszeit. Bei Unklarheiten sichern Sie Belege und nutzen den Leitfaden zu EA-Fehlern. Lockern Sie keine Spread- oder Risikolimits, ändern Sie keine Magic Numbers und erzwingen Sie keinen Einstieg, nur um eine grüne Anzeige zu erhalten.

Verbunden bedeutet nicht: aktuelle Kurse

IsConnected() meldet die Verbindung des Terminals zum Server. Die Funktion bestätigt weder frische Daten jedes Symbols noch Handelszugriff oder eine fehlerfreie Strategie. Prüfen Sie genaue Symbolnamen einschließlich Broker-Suffixen und die Daten, die der EA zusätzlich zu seinem eigenen Chart benötigt.

MarketInfo(symbol, MODE_TIME) liefert den Zeitpunkt des letzten eingegangenen Ticks für dieses Symbol auf Basis der Broker-Serverzeit. Der letzte Kurs ist ein historischer Nachweis, keine Uhr, die ohne neue Ticks weiterläuft. An Wochenenden, in Handelspausen und ruhigen Phasen kann ein älterer Kurs normal sein. Prüfen Sie den tatsächlichen Broker-Zeitplan, bevor Sie einen Datenfehler annehmen.

Legen Sie Prüfungen des Kursalters je Symbol und Sitzung erst nach Beobachtung des Normalbetriebs fest. Es gibt keinen universell sicheren Grenzwert für alle Forex-Paare und EAs. Auch ein unveränderter Bid reicht als Beleg nicht aus: Mehrere Ticks können denselben Preis enthalten. Erfassen Sie nach Möglichkeit den Eingang von Datenereignissen statt nur Preisänderungen.

Für jede Frage die passende Zeitbasis verwenden

Ziehen Sie Broker-Kurszeit nicht direkt von der Windows-Uhr ab, um das Kursalter zu bestimmen, ohne eine gemeinsame Zeitbasis nachzuweisen. Entwickler können Intervalle mit einem geeigneten Zähler messen, müssen aber Rücksetzungen und Überläufe behandeln. Ein externer Datensammler sollte fehlende Berichte anhand seiner eigenen getesteten Zeitmessung beurteilen, getrennt von Marktzeitstempeln.

Versehen Sie Protokollzeiten mit Quelle, Datum und Zeitzone. Vereinheitlichen Sie Zeitbasen vor der Rekonstruktion eines Vorfalls. Zwei ähnlich aussehende Uhrzeiten auf einem Bildschirm belegen keine Ereignisreihenfolge. Siehe den Leitfaden zu Experts und Journal.

Festlegen, was ein Heartbeat wirklich belegt

Ein Heartbeat ist eine regelmäßige Statusmeldung eines benannten Bestandteils. Ein VPS-Heartbeat betrifft den Rechner, eine Meldung eines Überwachungs-EA dessen eigene Ereignisverarbeitung. Beides beweist nicht automatisch, dass ein anderer Handels-EA ein Signal ausgewertet oder einen Positionskorb verwaltet hat.

OnTick() wird bei neuen Ticks des Symbols ausgeführt, auf dessen Chart der EA läuft. Eine nur dort gesendete Meldung kann ohne Ticks ausbleiben. Falls der Entwickler es umgesetzt hat, kann das Programm mit EventSetTimer() und OnTimer() regelmäßige Ereignisse anfordern. Timer-Ereignisse stehen in einer Warteschlange; ist bereits eines vorgemerkt oder in Bearbeitung, wird kein weiteres hinzugefügt. Das ist keine präzise externe Uhr und keine Zusage, dass ein blockiertes Programm weiter meldet.

Fragen Sie, welcher Kontrollpunkt die Meldung erzeugt: Eintritt in einen Handler, abgeschlossene Datenprüfung, abgeschlossener Verwaltungszyklus oder erfolgreiche Übertragung. Hilfreich sind Instanzkennung, Version, Sequenznummer, Betriebsmodus, Datenstatus sowie Erzeugungs- und Empfangszeit. Eine steigende Sequenz trennt neue Meldungen von Wiederholungen, beweist aber keine Orderausführung.

Bei einem EA ohne zugänglichen Quellcode nutzen Sie unterstützte Anbieteranzeigen und externe Beobachtungen. Ein hinzugefügter Beobachter erhält dadurch keinen Einblick in die interne Funktionsfähigkeit der Strategie. Ein separater Überwachungs-EA braucht einen eigenen Chart: Auf dem Strategiechart würde er den vorhandenen EA ersetzen. Er sollte nur beobachten, keine Trades senden und keine Strategie-Orders verwalten.

Ausbleibende Berichte außerhalb des Terminals erkennen

Ein gestopptes Terminal kann seine letzte Ausfallmeldung nicht zuverlässig selbst senden. Ein unabhängiger Beobachter kann fehlende erwartete Berichte erkennen, solange er selbst, seine Verbindung und der Alarmweg funktionieren. Liegt der einzige Wächter auf demselben VPS, ist er demselben Rechnerausfall ausgesetzt.

Trennen Sie Datenerfassung und Eingriff. Ein Alarm über fehlende Meldungen bedeutet, dass irgendwo bei Sender, Netzwerk, Datensammler oder Alarmweg die Beobachtung ausfiel. Er beweist nicht, dass der primäre EA aufgehört hat zu handeln, und darf keine Ersatzinstanz automatisch freigeben. Prüfen Sie Rechner und aktuelle Broker-Orders vor der Übergabe nach Leitfaden 3.

Vergeben Sie für jede vorgesehene Instanz eine eindeutige Überwachungskennung und erkennen Sie unbekannte oder doppelte Sender. Überwachen Sie auch den Datensammler und testen Sie einen alternativen Kontaktweg. Übertragen Sie nur nötige Statusdaten; Passwörter, Aktivierungsgeheimnisse und unbeschränkter Kontozugriff gehören nicht in einen Heartbeat.

Berechtigungen überwachen, ohne sie blind zu aktivieren

Im normalen Desktop-MT4 prüfen Sie AutoTrading, die eigene Handelsberechtigung des EA, den Handelszugriff des vorgesehenen Kontos und die Anbieterlizenz. Ein Nur-Lese-Zugang kann Kontodaten anzeigen, aber Handel verhindern. Nach einer Berechtigungsänderung kann ein EA weiter rechnen, ohne die vorgesehenen Orderänderungen ausführen zu können.

IsTradeAllowed() ohne Argumente prüft die Berechtigung des aufrufenden EA und ob der Handelskontext belegt ist. false liefert keine vollständige Diagnose; true garantiert nicht, dass der Broker die nächste Anfrage annimmt. Das Ergebnis eines separaten Beobachters bestätigt nicht die individuelle Berechtigung eines anderen EA.

Melden Sie unerwartete Abweichungen vom freigegebenen Betriebsmodus. Ein absichtlich pausiertes Terminal gehört als pausiert dokumentiert; ein Wächter soll es nicht eigenständig „reparieren“. Deaktivierte Automatisierung schließt keine Positionen und kann lokale Ausstiegslogik unterbrechen. Jede Pause braucht einen ausdrücklichen Verwaltungsplan.

Fehlgeschlagene Anfragen und bestehende Positionen prüfen

Verfolgen Sie eine dokumentierte Handelsanfrage über geplante Aktion, Versuch, Rückmeldung und Abgleich mit Broker-Daten. Ablehnungen und fehlgeschlagene Änderungen sind auch ohne neue Position relevant. Protokolliert der Anbieter weder Versuche noch Gründe für ausgelassene Signale, lassen sich diese Informationen nicht zuverlässig allein aus der Orderliste rekonstruieren.

Fehler 128 bezeichnet einen Handels-Timeout. Bei verlorener oder unklarer Antwort prüfen Sie offene und ausstehende Orders sowie den relevanten Verlauf, bevor Sie eine Wiederholung erwägen. Fehlende lokale Bestätigung beweist keine Ablehnung. Erfassen Sie genaues Symbol, Richtung, Volumen, Ticket soweit bekannt und Anfragezeit; raten Sie nicht, welche Order zum Versuch gehört.

Prüfen Sie aktuelle Exposition, schwebenden Gewinn/Verlust, Equity und akzeptierte Stop-Loss-/Take-Profit-Niveaus gemeinsam mit den dokumentierten Zuständigkeitsregeln des EA. Brokerseitiger Schutz unterscheidet sich von einem vorgesehenen virtuellen Stop oder einer späteren Trailing-Anpassung. Ein gestoppter EA kann Positionen offen lassen; ausstehende Orders können bei fehlender lokaler Überwachung ausgelöst werden. Dieser Leitfaden definiert weder eine neue Drawdown-Grenze noch eine automatische Liquidationsregel.

Alarmmeldungen bis zum Empfänger testen

1. Öffnen Sie im vorgesehenen Terminal Tools → Options → Notifications, aktivieren Sie Push-Nachrichten und tragen Sie die MetaQuotes ID des vorgesehenen mobilen Terminals ein.
2. Nutzen Sie Test, prüfen Sie das Ergebnis im Terminal und den tatsächlichen Empfang auf dem Gerät. Kontrollieren Sie dessen Benachrichtigungsrechte und den praktischen Reaktionsweg.
3. Testen Sie die wirkliche Alarmbedingung des EA oder Beobachters separat. Ein Einstellungstest beweist nicht, dass eine Regel für fehlende Heartbeats oder abgelehnte Anfragen existiert.
4. Dokumentieren Sie Testzeit, Sender, Ziel und Ergebnis. Wiederholen Sie nach VPS-Migration, Gerätewechsel oder geänderten Benachrichtigungen.

Notify of trade operations erfasst erfolgreiche Handelsvorgänge und dokumentierte Kontoereignisse, aber keine erfolglosen Handelsvorgänge. Die Funktion ist deshalb keine vollständige Überwachung für Ablehnungen, veraltete Daten oder Terminalausfälle.

Für eigenes SendNotification() dokumentiert MetaQuotes maximal 255 Zeichen, 2 Aufrufe pro Sekunde und 10 pro Minute. Überschrittene Frequenzlimits können die Funktion deaktivieren. Sie funktioniert nicht im Strategy Tester; prüfen Sie die Zustellung in einer geeigneten laufenden Demo-Umgebung. Ein erfolgreiches Sendeergebnis belegt weder Lesen noch Bestätigung durch eine Person. Fassen Sie wiederholte Fehler zusammen und melden Sie sinnvolle Zustandswechsel statt jeden Tick.

Alarmregeln mit Kontext und nächstem Schritt formulieren

Legen Sie Mindestdauer der Bedingung, Wiederholungsabstand, Bestätigung und Entwarnungskriterium fest. Eine Entwarnung muss benennen, welche Beobachtungen wieder möglich sind; ein neuer Heartbeat beweist nicht die Erholung aller Ebenen. Nutzen Sie ein ausdrückliches Wartungsfenster mit Verantwortlichem und Endzeit, statt einen häufigen Alarm dauerhaft stummzuschalten.

Bewerten Sie die Dringlichkeit nach der tatsächlichen Kontosituation. Dasselbe Datenproblem kann ohne Exposition anders wirken als bei Positionen mit lokalen Ausstiegen. Die Überwachung erkennt diese Lage, liefert aber keine universell sichere Wartefrist.

Ein Beispiel für fehlende Heartbeats mit einer Zeitbasis

Hypothetisches Beispiel: Ein Datensammler erwartet alle 60 Sekunden einen identifizierten Bericht und alarmiert nach 180 Sekunden ohne neue Meldung. Das sind Lehrwerte, keine allgemein empfohlenen Grenzwerte. Alle folgenden Zeiten sind Beobachtungszeiten des Datensammlers in UTC; Broker-Kurszeiten werden nicht davon abgezogen.

Damit verstrichen 180 ÷ 60 = 3 erwartete Meldeintervalle ohne neuen Empfang. Das beweist nicht, dass der Handel um 10:00:00 stoppte, der Server etwas ablehnte oder die Order unverwaltet ist. Prüfen Sie EA, Protokolle und aktuellen Orderzustand vor einem Eingriff. War der Datensammler selbst ausgefallen, darf er keine lückenlose Beobachtung des ganzen Intervalls behaupten.

Ein kurzes Betriebsprotokoll führen

Erfassen Sie letzte erfolgreiche Prüfung, Datenstatus benötigter Symbole, EA-/Terminalkennung, Zuständigkeit für offene Orders, ungeklärte Meldungen, Alarmtestergebnis und geplante Änderungen. Prüfen Sie nach Einrichtung, Neustart, Migration, freigegebenen Parameteränderungen und Broker-Wartung. Wählen Sie danach eine Frequenz passend zu den tatsächlichen Verwaltungsaufgaben des EA.

Öffentliches Monitoring hilft bei der Leistungsbewertung, doch prüfen Sie zuerst letzte Aktualisierung und Veröffentlichungsverzögerung. Eine schöne Kontostandskurve ist keine Echtzeit-Funktionsprüfung. Ein ruhiger Bericht oder unveränderter Kontostand unterscheidet Warten auf ein Signal nicht vom Terminalausfall. Leistungsbewertung und unmittelbare Betriebsüberwachung sind getrennte Aufgaben.

Die tatsächlich handelnde Umgebung beobachten

Auf einem Windows-VPS können Rechner-/Prozessprüfungen, Terminalbeobachtungen und unabhängige Datensammlung verschiedene Ausfallwege abdecken. Nutzen Sie Leitfaden 2 für Ressourcen und Startverhalten; eine erfolgreiche Windows-Anmeldung bestätigt keinen funktionsfähigen EA.

Beim integrierten virtuellen MetaTrader-Hosting prüfen Sie entfernten Betriebsstatus, Synchronisierung und angeforderte Terminal-/Experts-Protokolle über dessen Steuerung. Ein lokaler Chart oder Heartbeat zeigt den entfernten EA nicht. Ein dortiger Heartbeat muss gezielt bereitgestellt, kompatibel und in dieser Umgebung getestet sein. Windows-Dienste und nicht unterstützte DLL-Werkzeuge lassen sich nicht einfach übertragen.

Lokales AutoTrading stoppt die gehostete Kopie nicht. Nutzen Sie bei einem Eingriff die Hosting-Steuerung und prüfen Sie den tatsächlichen entfernten Status. Die Überwachung muss Primärhost, lokales Vorbereitungsterminal und Ersatzinstanz unterscheiden können.

Überwachungslücken auf Demo erproben

Verwenden Sie eine berechtigte Demo-Umgebung mit eigenen Zustandsdateien. Testen Sie kontrolliertes Schließen des Terminals, Ausfall des Meldewegs, erwartete Handelspausen, absichtliches Pausieren und Rückkehr zum Normalbetrieb. Unterscheiden Sie einen tatsächlichen Alarm von einem erfolgreichen Zustelltest. Lassen Sie keine Live-Position unverwaltet, nur um einen Wächter zu testen.

Halten Sie getestete Konfiguration, Beobachtungen und verbleibende blinde Flecken fest. Gute Überwachung reduziert Unsicherheit; sie garantiert weder Verfügbarkeit noch Ausführung oder Strategieerfolg.

Häufige Fragen zur EA-Überwachung

Bedeutet kein neuer Trade, dass der EA defekt ist?

Nein. Prüfen Sie Handelszeiten, Signalregeln, Daten, Berechtigungen und Verwaltung bestehender Orders. Eine intakte Strategie kann berechtigt untätig bleiben.

Belegt ein Heartbeat alle EA-Funktionen?

Nein. Er belegt nur die Erzeugung oder den Empfang der dokumentierten Meldung. Entscheidend sind ihr Erzeugungsort und die Aktualität ihrer Felder.

Erkennen normale Push-Nachrichten jeden Ausfall?

Nein. Meldungen erfolgreicher Trades lassen erfolglose Vorgänge aus; ein gestopptes Terminal kann seinen vollständigen Ausfall nicht zuverlässig melden. Testen Sie eigene Regeln und unabhängige Erkennung fehlender Berichte getrennt.

Soll ein fehlender Heartbeat automatisch einen Ersatz-VPS starten?

Nein. Klären Sie zuerst Handelsstatus der Primärinstanz, aktuelle Broker-Orders und deren Verwaltung. Eine fehlende Meldung erlaubt keine doppelte Automatisierung.

Offizielle Quellen und praktische Grenzen

Plattformdetails wurden anhand offizieller MetaQuotes-Dokumentation geprüft. Prüfungsformat, Beispielgrenzen und Vorfallregeln sind praktische Lehrhinweise, kein bereitgestelltes Überwachungsprodukt oder gemessenes Zuverlässigkeitsergebnis. Oberflächenbezeichnungen hängen von der Terminalsprache ab; prüfen Sie Ihre Installation.

• MQL4: Verbindungszustand und EA-Handelsberechtigung.
• MQL4: Kurszeitstempel, Serverzeitverhalten und Timer-Grenzen.
• MetaTrader 4: Benachrichtigungseinstellungen; MQL4: Grenzen eigener Push-Nachrichten.
• MetaTrader 4: Remote-Hosting-Status und Protokolle.