Über Strategien wird viel geschrieben, über Infrastruktur fast nie. Dabei entscheidet sie in der Praxis häufiger über das Ergebnis als der Indikator: Ein Bot, der zum falschen Zeitpunkt nicht läuft, hat keine Strategie — er hat eine offene Position ohne Aufsicht.
Was Ausfall wirklich bedeutet
Ein Absturz ist selten neutral. Er trifft Sie in genau drei Zuständen, und jeder hat eigene Konsequenzen:
- Flat (keine Position): harmlos — Sie verpassen Signale.
- Position offen, Stop an der Börse platziert: Der Schutz greift, die Strategie ist blind.
- Position offen, Stop nur lokal im Bot: Das ist der gefährliche Fall. Der Ausstieg existiert nur im abgestürzten Prozess.
Daraus folgt die wichtigste Regel jeder Bot-Infrastruktur: Schutz-Orders gehören an die Börse, nicht in den Arbeitsspeicher.
Der Stop, der nur im Code existiert, ist kein Stop. Er ist eine Absicht.
Hosting: nicht auf dem Laptop
Ein produktiver Bot läuft auf einem Server, nicht auf einem Rechner mit Standby-Modus, Windows-Updates und WLAN. Sinnvolle Kriterien für die Auswahl:
- Region nahe am Handelsplatz — Latenz ist für die meisten Strategien unkritisch, für einige entscheidend.
- Zeitsynchronisation (NTP). Viele Börsen-APIs weisen Requests mit abweichendem Zeitstempel ab.
- Getrennte Umgebungen für Test und Live. Nie beide Bots mit denselben Keys auf derselben Maschine.
- Rechte-Trennung. API-Keys ohne Auszahlungsrecht, IP-Whitelisting aktiv.
Watchdog und Wiederanlauf
Ein Prozess wird abstürzen — nicht ob, sondern wann. Deshalb gehört ein Neustartmechanismus dazu (Prozess-Manager, Container-Restart-Policy). Der kritische Teil ist nicht der Neustart, sondern der Wiederanlauf: Der Bot muss beim Start prüfen, welche Positionen und offenen Orders bei der Börse tatsächlich existieren, und seinen internen Zustand daraus rekonstruieren — niemals aus einer lokalen Datei, die beim Absturz veraltet sein kann.
Das nennt sich Zustandsabgleich (State Reconciliation) und ist der Unterschied zwischen einem Bot, der sauber weiterläuft, und einem, der nach dem Neustart eine Position doppelt eröffnet.
Idempotenz: die Versicherung gegen Doppelorders
Wenn eine Order abgeschickt wurde und die Antwort verloren geht, weiß der Bot nicht, ob sie angekommen ist. Ohne Schutz sendet er sie erneut — und Sie haben die doppelte Position. Die Lösung: jede Order bekommt eine eindeutige, vom Client vergebene ID. Die Börse lehnt die zweite Order mit derselben ID ab. Das ist eine Zeile Aufwand und verhindert die teuerste Fehlerklasse überhaupt.
Monitoring statt Hoffnung
- Heartbeat: Der Bot meldet alle 60 Sekunden „ich lebe". Bleibt das Signal aus, erhalten Sie eine Nachricht.
- Alarm bei Fehlerraten der API — nicht erst beim Totalausfall.
- Kill-Switch: Ein Befehl, der alle Positionen schließt und den Bot stoppt. Vorher getestet, nicht im Ernstfall geschrieben.
Failover — und wann er zu viel ist
Ein zweiter Server, der im Fehlerfall übernimmt, klingt richtig, erzeugt aber ein neues Risiko: Wenn beide gleichzeitig laufen, handeln beide. Wer Failover baut, braucht eine eindeutige Sperre (Leader-Election), damit immer nur eine Instanz aktiv ist. Für die meisten privaten Setups ist der einfachere Weg besser: ein Server, ein Watchdog, Schutz-Orders an der Börse, Kill-Switch griffbereit.
Fazit
Uptime ist keine technische Nebensache, sondern Teil des Risikomanagements. Schutz-Orders an der Börse, Zustandsabgleich beim Start, eindeutige Order-IDs und ein funktionierender Kill-Switch machen aus einem Skript ein System.
Dieser Beitrag ist rein edukativ und stellt keine Anlageberatung dar. Automatisierter Handel ist mit erheblichen Risiken bis zum Totalverlust verbunden. Jede Umsetzung erfolgt auf eigene Verantwortung.