Mining-Monitoring und Alerts: Downtime in Minuten erkennen, nicht erst nach einem Tag

Downtime auf einer Farm sieht fast nie dramatisch aus. Das Licht geht nicht aus, es raucht nichts. Irgendwann hören einfach einige Maschinen auf, Shares zu liefern, und man merkt es erst am Morgen, wenn die Auszahlung niedriger ausfällt als am Vortag. Zu diesem Zeitpunkt ist das Geld bereits verloren und lässt sich nicht zurückholen: Das Netzwerk berechnet Ihren Anteil nicht rückwirkend neu.

Im Folgenden erklären wir, warum das Pool-Dashboard schlecht als Alarmsystem taugt, welche Kennzahlen einen Ausfall frühzeitig ankündigen und wie man mit vorhandenen Mitteln eine einfache Benachrichtigung aufbaut.

Was eine Stunde Downtime kostet

Wir rechnen mit der Formel, die jeder Rentabilitätsrechner verwendet:

\`\`\`

BTC pro Tag = (Hashrate × 86400) / (Difficulty × 2^32) × 3.125

\`\`\`

Dabei sind 86400 die Sekunden pro Tag, 2^32 stammt aus der Definition der Difficulty, und 3.125 BTC ist die aktuelle Block-Subvention (Wert aus unserem Netzwerk-Snapshot vom 08.09.2026).

Setzt man eine Difficulty von 127,45 Billionen (mempool.space, 08.09.2026) und einen Kurs von 78.349 Dollar ein:

Die Rechnung ist brutto, vor Pool-Gebühr und Strom, und berücksichtigt keine Transaktionsgebühren (laut mempool.space erhöhten sie am 08.09.2026 die Belohnung in einem Fenster von 4320 Blöcken um 0,66%, größenordnungsmäßig ändert das also fast nichts).

Danach folgt einfache Arithmetik. Ein Ausfall um ein Uhr nachts, bemerkt um ein Uhr mittags. Zwölf Stunden, Farm mit 10 PH/s: etwa 193 Dollar, die einfach nicht in der Auszahlung landen. Passiert das einmal im Monat, kostet es Sie im Jahr über zweitausend Dollar bei völlig funktionsfähiger Hardware.

Warum das Pool-Dashboard kein Monitoring ersetzt

Kurz gesagt: Der Pool zeigt nicht den Zustand Ihrer Hardware, sondern den Zustand des Share-Stroms, der bei ihm angekommen ist. Zwischen dem Abbruch und der Statusänderung im Dashboard vergehen Dutzende Minuten, weil der Pool einen echten Ausfall von einem gewöhnlichen Verbindungsabbruch unterscheiden muss. Bei AntPool ist das offiziell geregelt: Ein Worker erhält den Status Inactive nach 20 Minuten ohne Shares, und den Status Invalid erst nach 24 Stunden Stille (AntPool support, Worker Management).

Zwanzig Minuten sind bei 10 PH/s bereits 5,4 Dollar, und das ist noch der beste Fall: Der Worker ist komplett ausgefallen und der Status ändert sich tatsächlich. Wenn die Maschine läuft, aber nur die Hälfte liefert, bleibt der Status grün, und der Pool sagt Ihnen nichts.

Es gibt noch einen zweiten Grund. Der Hashrate im Pool-Dashboard ist keine Messung, sondern eine Schätzung anhand der Zahl akzeptierter Shares in einem Mittelungsfenster. Jeder Pool hat sein eigenes Fenster, und in der Dokumentation steht es nicht immer. Je kürzer das Fenster, desto nervöser der Graph; je länger, desto später reagiert er auf einen echten Einbruch.

Die Werte für Verzögerungen und Schwellen bei anderen Pools prüfen Sie bitte in deren eigener Dokumentation: offiziell bestätigte Zahlen haben wir nur bei AntPool gefunden, und man kann sie nicht auf andere Pools übertragen.

Drei Beobachtungsebenen

Man kann an drei Stellen beobachten, und jede sieht nur ihren Teil des Bildes.

Keine Ebene ist für sich genommen ausreichend. Der Miner meldet ehrlich eine Überhitzung, schweigt aber, wenn Ihr Provider die Route zum Pool gekappt hat. Der Pool sieht das Verschwinden der Shares, aber mit Verzögerung und ohne Erklärung der Ursache. Der Stromsensor reagiert sofort, unterscheidet aber nicht zwischen einer ausgeschalteten und einer abgestürzten Maschine.

Das funktionale Minimum sind die erste und die dritte Ebene: lokale Daten für die Ursache, Pool-Daten zur Kontrolle, dass die Arbeit tatsächlich vergütet wird.

Welche Kennzahlen einen Ausfall frühzeitig ankündigen

Direkte Antwort: der Anteil abgelehnter Shares, eine anhaltende Abweichung zwischen lokalem und Pool-Hashrate, die Chip-Temperatur und der Neustart-Zähler. Diese vier Werte ändern sich, bevor die Maschine komplett ausfällt, und geben Zeit zum Eingreifen, bevor der Downtime vollständig wird.

1. Abgelehnte Shares (Reject Rate). Ein wachsender Anteil an Ablehnungen ist fast immer das Netzwerk: Paketverlust, überlasteter Router, schlechte Route zum Pool-Server. Suchen Sie die Norm für Ablehnungen nicht in fremden Artikeln, sondern in Ihren eigenen Daten über eine ruhige Woche: Jede Kombination aus Hardware und Provider hat ihre eigene.
2. Die Lücke zwischen lokalem und Pool-Hashrate. Dazu weiter unten ein eigener Abschnitt, denn hier gerät man am häufigsten grundlos in Panik.
3. Chip-Temperatur und Lüfterdrehzahl. Ein verstaubter Kühlkörper lässt die Temperatur allmählich steigen. Die Maschine drosselt zunächst selbst die Frequenz und verliert dabei still Prozente an Rentabilität, erst danach geht sie in den Schutzmodus. Genau diese Phase der stillen Degradation lässt sich mit einer Temperaturschwelle gut erfassen.
4. Uptime-Zähler. Wenn die Uptime der Maschine regelmäßig zurückgesetzt wird, haben Sie Neustarts, von denen der Pool nichts erzählt: Zwischen den Neustarts laufen Shares, der Status ist grün, aber die Gesamtproduktion ist niedriger.
5. Anzahl funktionierender Hashboards. Ein ausgefallenes Board bei einer Drei-Board-Maschine bedeutet ein Drittel weniger Ertrag, während der Worker im Dashboard vollständig lebendig erscheint.

Warum der Pool immer weniger anzeigt als der Miner selbst

Direkte Antwort: Der Miner zeigt die Rechengeschwindigkeit, die er selbst ermittelt hat, und der Pool zeigt eine Schätzung, die aus den akzeptierten Shares rekonstruiert wird. Der zweite Wert ist statistisch, schwankt daher und liegt im Durchschnitt niedriger: Ein Teil der Arbeit geht in abgelehnte und verspätete Shares, ein Teil geht in der Rundung des Mittelungsfensters verloren.

Die praktische Regel ist einfach. Eine Abweichung von wenigen Prozent, die im Laufe des Tages hin und her schwankt, ist normale Stichprobenstreuung, kein Defekt. Das echte Signal sieht anders aus: Der Pool-Hashrate sinkt und bleibt dort, während sich der lokale nicht ändert. Ein solches Bild bedeutet, dass die Maschine rechnet, das Ergebnis aber nicht beim Pool ankommt oder nicht gezählt wird.

Wie groß die Norm für genau Ihre Kombination ist, kann Ihnen niemand vorhersagen. Sammeln Sie eigene Zahlen über eine ruhige Woche, berechnen Sie das durchschnittliche Verhältnis von Pool- zu lokalem Hashrate und richten Sie sich danach. Genauso sollte man mit allen Schwellen unten verfahren.

Wie man ohne Drittanbieter-Dienste eine Benachrichtigung aufbaut

Man braucht irgendeine Maschine, die rund um die Uhr läuft und HTTP-Anfragen stellen kann: einen heimischen Mini-Server, einen Router mit Skriptfunktion, einen alten Laptop. Danach zwei Datenquellen.

Auf Seiten des Miners. Das Web-Interface des ASIC liefert aktuellen Hashrate, Temperaturen, Drehzahlen, Uptime, Zustand der Hashboards und Ablehnungszähler. Bei vielen Firmwares stehen dieselben Daten auch maschinenlesbar über eine lokale API oder einen Management-Socket zur Verfügung. Genaue Adressen und Format hängen vom Hersteller und der Firmware-Version ab, siehe die Dokumentation Ihres Modells.

Auf Seiten des Pools. Manche Pools haben eine Konto-API mit Hashrate der Worker und deren Status über einen Schlüssel aus dem persönlichen Bereich. Verfügbarkeit, Format und Anfragenlimits unterscheiden sich je Pool und müssen in der jeweiligen Dokumentation geprüft werden: Einen einheitlichen Standard gibt es hier nicht, und wir haben keine Endpoints über das hinaus bestätigt, was in unseren Berichten beschrieben ist.

Die Skriptlogik passt in ein Dutzend Zeilen: einmal pro Minute die Miner abfragen, alle paar Minuten den Pool abfragen, die Werte mit den Schwellen vergleichen, bei Verstoß eine Nachricht an Messenger oder E-Mail senden. Sehen Sie auch das Umgekehrte vor: Wenn das Skript selbst länger als eine halbe Stunde schweigt, ist es abgestürzt, nicht die Farm. Ein schweigender Monitor ist die schlimmste Art von Monitor, weil er ein Gefühl von Kontrolle erzeugt, das nicht existiert.

Welche Schwelle setzen, um nicht in Fehlalarmen zu ertrinken

Direkte Antwort: nicht nach einer einzelnen Messung, sondern nach mehreren hintereinander. Die Suche nach Shares ist ein Zufallsprozess, und kurze Einbrüche im Graph sind selbst bei einer intakten Farm unvermeidlich. Die Schwelle muss verlangen, dass die Abweichung mehrere Abfrageintervalle in Folge anhält, sonst bekommen Sie stündlich Benachrichtigungen und hören sehr schnell auf, sie zu lesen.

Ein praktisches Schema sieht so aus:

1. Völliges Schweigen des Miners. Die lokale Abfrage antwortet zweimal hintereinander nicht. Das ist keine Streuung mehr, sofort reagieren.
2. Hashrate-Einbruch. Wert unter Ihrer üblichen Norm und über mehrere Messungen hintereinander dort. Wie weit darunter und über wie viele Messungen, bestimmen Sie anhand Ihrer eigenen Historie über eine ruhige Woche.
3. Temperatur. Nehmen Sie die Schwelle aus der Herstellerdokumentation Ihres Modells und setzen Sie den Alarm mit Abstand unter der Auslösetemperatur des Schutzes, um vor einer Notabschaltung reagieren zu können.
4. Abgelehnte Shares. Vergleichen Sie mit Ihrem eigenen ruhigen Hintergrund, nicht mit einer absoluten Zahl aus dem Internet.
5. Schweigen des Pools. Nützlich, aber denken Sie an die Verzögerung: Bei AntPool erscheint sogar der offizielle Status Inactive erst nach 20 Minuten. Dieser Alarm kommt immer nach dem lokalen.

Noch eine Regel: Jeder Alarm braucht eine Ruhezeit nach dem Auslösen. Sonst wird aus einem Ausfall um drei Uhr nachts vierzig identische Nachrichten, und morgens räumen Sie Benachrichtigungen weg statt sich um die Farm zu kümmern.

Entscheiden Sie separat, was im Moment des Auslösens zu tun ist. Steht die Farm nicht bei Ihnen zu Hause, wird eine Benachrichtigung ohne Möglichkeit zur Fernwirkung zu einer Methode, sich die Nacht zu verderben. Hier schließt sich das Thema Backup-Pool an: Ein Teil der Ausfälle ist kein Hardwaredefekt, sondern ein Problem auf Seiten des Pools oder der Route dorthin, und das löst man durch automatisches Umschalten, nicht durch Anfahrt. Über die Einrichtung einer Backup-Adresse haben wir gesondert geschrieben.

Checkliste für einen Abend

1. Berechnen Sie mit der obigen Formel Ihre eigenen Kosten einer Stunde Downtime. Eine einzige Zahl macht den ganzen weiteren Aufwand sinnvoll.
2. Erstellen Sie eine Basislinie: lokaler Hashrate, Pool-Hashrate, Temperaturen, Ablehnungsanteil an einem ruhigen Tag.
3. Prüfen Sie, ob Ihre Firmware maschinenlesbare Daten liefert, und notieren Sie die Adresse.
4. Prüfen Sie in der Dokumentation Ihres Pools, ob es eine Konto-API gibt und welche Einschränkungen sie hat.
5. Schreiben Sie eine Abfrage der Miner einmal pro Minute mit Aufzeichnung in eine Datei oder eine einfache Datenbank.
6. Richten Sie vier Alarme ein: keine Antwort, Hashrate-Einbruch, Temperatur, steigende Ablehnungen.
7. Fügen Sie eine Ruhezeit nach dem Auslösen und einen Schutz vor einem schweigenden Monitor hinzu.
8. Testen Sie alles ehrlich: Ziehen Sie das Netzwerkkabel einer Maschine und stoppen Sie, nach welcher Zeit die Nachricht eintrifft.
9. Tragen Sie einen zweiten Pool in den Miner-Einstellungen ein, falls noch nicht geschehen.
10. Überprüfen Sie nach einer Woche die Schwellen anhand der gesammelten Daten. Beim ersten Mal treffen sie fast nie.

Punkt acht wird am häufigsten übersprungen, dabei ist er der einzige, der beweist, dass das System überhaupt funktioniert.

Was Sie als Nächstes lesen sollten

• Mining-Rentabilitätsrechner: Geben Sie Ihren eigenen Hashrate ein und sehen Sie, was ein Tag Downtime persönlich für Sie kostet.
• Der Pool ist down: wie man erkennt, dass es nicht an der eigenen Farm liegt: wie man ein Problem auf der eigenen Seite von einem auf der Pool-Seite unterscheidet.
• Backup-Pool: warum eine zweite Adresse eintragen: Umschalten bei einem Ausfall ohne Ihr Zutun.
• Vergleich von Mining-Pools: Gebühren, Auszahlungsschemata und Auszahlungsschwellen.

Monitoring erhöht nicht den Ertrag. Es verhindert lediglich, dass Sie verlieren, was Sie bereits verdient haben, und im Mining ist der Unterschied zwischen diesen beiden Dingen verschwindend gering.