Bestell-Heartbeat: Alarm, wenn keine Bestellung mehr kommt

Warum ein stiller Checkout-Ausfall stundenlang unbemerkt bleibt

Die meisten Störungen im Onlinehandel sind keine Totalausfälle, sondern Defekte an genau einer Stelle der Kasse. Ein Plugin-Update ändert die Reihenfolge der Skripte, und das Zahlungsfenster lädt nicht mehr. Ein Zugangsschlüssel beim Zahlungsdienst läuft ab, und die Bestellung bleibt im Status „offen“ stehen. Eine neue Versandkostenregel liefert für bestimmte Postleitzahlen keinen Preis, und der Bestellknopf bleibt grau. In allen drei Fällen ist die Website erreichbar und der Warenkorb füllt sich, nur der letzte Schritt scheitert.

Ein klassischer Uptime-Check sieht davon nichts, denn er bewertet Statuscode und Antwortzeit einer Adresse. Auch die Abschlussquote verrät den Defekt nicht sofort, denn Kaufabbrüche sind der Normalfall: Über 50 Studien gemittelt liegt die dokumentierte Abbruchquote im Warenkorb bei 70,22 % (Baymard Institute). Ein paar Prozentpunkte mehr an einem Nachmittag fallen in einer Tagesauswertung kaum auf. Bemerkt wird der Ausfall dann am Abend in der Bestellübersicht oder am nächsten Morgen über eine Kundenmail.

Das Site-Reliability-Handbuch von Google trennt dafür zwei Fragen: was kaputt ist und warum (Google SRE Book). Alarmiert werden soll vor allem auf Symptome, auf Ursachen nur, wenn sie eindeutig sind und unmittelbar drohen (Google SRE Book). Für einen Shop ist das deutlichste Symptom schlicht, dass keine Bestellungen mehr ankommen. Ob die Ursache im Zahlungsmodul, in der Versandlogik oder beim Zahlungsdienst liegt, muss der Bestell-Heartbeat nicht wissen, um Alarm zu geben.

Your monitoring system should address two questions: what’s broken, and why?

— Google, Site Reliability Engineering, Kapitel 6 „Monitoring Distributed Systems“ (Originalzitat)

Im vierten Quartal wiegt jede Stunde schwerer. Rund jede und jeder Zweite (52 Prozent) wollte am Black Friday 2025 die reduzierten Preise nutzen, die allermeisten davon online; befragt wurden 1.120 Internetnutzende ab 16 Jahren (Bitkom). Für das Weihnachtsgeschäft 2025 erwartete der Handelsverband im Onlinehandel 22,2 Milliarden Euro Umsatz (HDE), und der Einzelhandel insgesamt erzielt 18,5 Prozent seines Jahresumsatzes im November und Dezember (HDE). Wie sich die Website selbst auf dieses Hochlastfenster vorbereiten lässt, beschreibt der Beitrag zu Lastspitzen im vierten Quartal.

Das Prinzip: Der Shop meldet, was er verkauft hat

Ein Heartbeat dreht die Überwachung um: Statt dass ein Prüfer von außen eine Seite abruft, meldet sich ein Prozess von innen in einem festen Takt. Bleibt die Meldung aus, gibt es einen Alarm. Dieses Totmannschalter-Prinzip erklärt der Beitrag zum Heartbeat-Monitoring für Cron-Jobs ausführlich. Beim Bestell-Heartbeat meldet sich ein kleiner Zähljob, der eine Geschäftszahl mitschickt: die Zahl der Bestellungen im letzten Zeitfenster, übergeben als Parameter items.

Die Heartbeats von XICTRAQ® werten diesen Parameter aus, wenn am Heartbeat die Einstellung „Job muss Output/Items liefern“ aktiv ist (Feld expect_output), auf Wunsch mit einer Mindestzahl (min_items). Daraus ergeben sich vier Zustände:

• Ping mit items ab der Mindestzahl: gesunder Lauf, ein offener Alarm wird automatisch aufgelöst.
• Ping mit items=0 oder unter der Mindestzahl: Alarm „Heartbeat ohne Ergebnis“ mit gemeldeter und erwarteter Zahl, Schwere Warnung. Der Zähljob lief, aber der Shop hat nichts oder zu wenig verkauft.
• Kein Ping bis zur nächsten Fälligkeit plus Toleranz: Alarm „Heartbeat verpasst“, Schwere kritisch. Der Zähljob selbst ist ausgefallen, etwa weil der Server steht oder der Cron-Dienst nicht läuft.
• Fehlermeldung über /fail oder exit_code ungleich 0: Alarm „Heartbeat fehlgeschlagen“, Schwere kritisch. Der Zähljob konnte nicht zählen und sagt das ausdrücklich.

Der dritte Zustand unterscheidet den Bestell-Heartbeat von einer Datenbankabfrage, die bei null Bestellungen eine Mail verschickt: Fällt deren Server aus, schweigt sie, und Schweigen sieht aus wie ein ruhiger Tag. Der Heartbeat erwartet die Meldung und schlägt an, wenn sie fehlt. Ein offener Alarm wird bei weiteren Läufen fortgeschrieben statt doppelt angelegt. Wer ihn über welchen Weg bekommt, legen die Alarmkanäle und Eskalationsstufen des Kontos fest.

Der Zähljob: eine Abfrage und ein Aufruf

Der Zähljob läuft dort, wo die Bestellungen liegen: auf dem Shop-Server oder einem Rechner mit Lesezugriff auf die Shop-Datenbank. Er braucht einen Datenbanknutzer mit reinen Leserechten, eine Abfrage und einen HTTP-Aufruf. Gezählt werden Bestellungen, die einen erfolgreichen Abschluss anzeigen, also ohne Storno und ohne Testkennzeichen. Wer nur bezahlte Bestellungen zählt, erkennt zusätzlich ausbleibende Zahlungsbestätigungen, muss aber Rechnungskauf und Vorkasse gesondert berücksichtigen. Tabellen- und Spaltennamen unterscheiden sich je Shopsystem; das Beispiel zeigt das Muster.

#!/usr/bin/env bash
# Zählt die Bestellungen der letzten N Minuten und meldet sie an einen Heartbeat.
# Aufruf: count-orders.sh <heartbeat-slug> <minuten>
set -euo pipefail

HB="https://api.xictraq.com/api/heartbeat/$1"
WINDOW="${2:-60}"

# Scheitert die Abfrage, meldet der Job sofort einen Fehlschlag, statt stumm abzubrechen.
trap 'curl -fsS -m 10 "$HB/fail?msg=Abfrage%20fehlgeschlagen" >/dev/null' ERR

# created_at liegt in UTC, deshalb UTC_TIMESTAMP() statt NOW().
N=$(mysql --defaults-extra-file=/etc/shop/read-only.cnf -N -B -e "
  SELECT COUNT(*) FROM orders
  WHERE created_at >= UTC_TIMESTAMP() - INTERVAL ${WINDOW} MINUTE
    AND status NOT IN ('cancelled', 'test')")

curl -fsS -m 10 "$HB/ping?items=${N}" >/dev/null

Zwei Zeilen tragen die Last. Der trap meldet eine gescheiterte Abfrage sofort als Fehlschlag. Ohne ihn bräche das Skript wegen set -e stumm ab, und der Alarm käme erst nach Fälligkeit und Toleranz als „Heartbeat verpasst“, ohne Hinweis auf die Ursache. Mit ihm steht „Heartbeat fehlgeschlagen“ samt Grund sofort im Alarm, getrennt vom Fall „keine Bestellungen“. Ein Messausfall ist kein Messwert. Die letzte Zeile ist der eigentliche Ping; weitere Parameter wie exit_code, duration_ms oder eine Notiz über msg beschreibt die Heartbeat-Dokumentation.

Bevor der Heartbeat scharf geschaltet wird, lohnt eine Gegenprobe von Hand. Ein Ping mit items=0 muss den Leerlauf melden, ein Ping mit einer normalen Zahl darf es nicht:

Wie viele Bestellungen sind normal? Die Schwelle berechnen

Die wichtigste Entscheidung ist die Schwelle, und sie hängt an der eigenen Bestellrate. Bestellungen treffen zufällig verteilt ein. Für solche Zählungen eignet sich die Poisson-Verteilung, die die Zahl der Ereignisse in einem festen Zeitintervall modelliert (NIST); ihr Parameter λ ist die mittlere Zahl der Ereignisse im Intervall (NIST). Die Wahrscheinlichkeit, dass in einem ungestörten Fenster keine einzige Bestellung eingeht, beträgt damit e hoch minus λ. Die Tabelle zeigt, was das für einen Zähljob bedeutet, der tagsüber 15-mal läuft.

Eine starre Regel „null Bestellungen in einer Stunde gleich Alarm“ taugt deshalb für viele Shops nicht. Bei durchschnittlich zwei Bestellungen je Stunde bliebe rechnerisch etwa jede siebte Stunde ohne Bestellung, ganz ohne Defekt (NIST), und der Alarm löste im Monat rund 60-mal grundlos aus. Das Site-Reliability-Handbuch beschreibt die Folge: Wer zu oft alarmiert wird, überfliegt oder übergeht Meldungen und übersieht dabei auch die echten (Google SRE Book). Ab fünf erwarteten Bestellungen je Fenster sinkt die Wahrscheinlichkeit für ein zufällig leeres Fenster unter ein Prozent.

Das Modell vereinfacht: Echte Bestellungen kommen gebündelt, etwa nach einem Newsletter, und dazwischen ist es ruhiger als gerechnet. Die Werte sind deshalb eine Untergrenze für Fehlalarme, keine Zusage. λ liest man aus den eigenen Daten ab: Bestellungen der letzten vier bis acht Wochen je Stunde und Wochentag auszählen, den Mittelwert bilden und nachzählen, wie oft eine Stunde tatsächlich leer war. Weicht dieser Anteil deutlich ab, gilt der eigene Wert.

Zählfenster, Takt und Mindestzahl aufeinander abstimmen

Drei Stellgrößen bestimmen, wie schnell und verlässlich der Heartbeat anschlägt: Länge des Zählfensters, Takt des Zähljobs und Mindestzahl. Fenster und Takt müssen nicht gleich lang sein. Ein Job, der alle 30 Minuten die letzten zwei Stunden zählt, hat ein großes λ und wenige Fehlalarme, merkt einen Totalausfall aber erst, wenn das ganze Fenster leer ist. Die Erkennungszeit eines Nullalarms liegt zwischen einer Fensterlänge und einer Fensterlänge plus einem Takt.

Mit min_items schlägt der Heartbeat nicht erst bei null an, sondern sobald weniger als die Mindestzahl gemeldet wird. Bei zehn erwarteten Bestellungen und einer Mindestzahl von drei löst der Zufall rechnerisch in rund 0,28 % der Läufe aus (NIST), bei einem Totalausfall kommt der Alarm aber früher, weil das Fenster nicht ganz leer sein muss. Wichtig: Die Mindestzahl ist ein fester Wert je Heartbeat. Eine Erwartung, die sich je Wochenstunde selbst anpasst, gibt es bei XICTRAQ® für die Laufzeit eines Jobs, nicht für die gemeldete Zahl. Unterschiedliche Erwartungen über den Tag bildet man mit mehreren Heartbeats ab.

Die Toleranz am Heartbeat, null bis 3.600 Sekunden, betrifft nur den ausbleibenden Ping und fängt ab, dass der Zähljob mal eine Minute später fertig wird. Der Alarm für zu wenige Bestellungen kommt mit dem Ping selbst, ohne Wartezeit.

Tag, Nacht und Wochenende: Zeitplan statt starrer Takt

Ein fester Stundentakt erwartet auch um drei Uhr nachts eine Meldung, und eine Mindestzahl, die tagsüber passt, löst nachts Fehlalarme aus. Heartbeats bei XICTRAQ® kennen deshalb zwei Erwartungsmodelle: ein festes Intervall zwischen einer Minute und 24 Stunden oder einen Cron-Plan mit eigener Zeitzone. Beim Cron-Plan wird die nächste Fälligkeit in der Zeitzone des Heartbeats berechnet; bleibt der Ping bis dahin plus Toleranz aus, folgt der Alarm.

Der Ausdruck folgt dem Crontab-Format mit fünf Zeitfeldern für Minute, Stunde, Tag, Monat und Wochentag, wobei beim Wochentag die 0 für Sonntag steht (POSIX). Ein Bindestrich beschreibt einen Bereich einschließlich beider Grenzen. 5 8-21 1-5 heißt also: montags bis freitags um 8:05, 9:05 und so weiter bis 21:05. Nach dem Lauf um 21:05 erwartet der Heartbeat den nächsten Ping erst um 8:05 am folgenden Werktag, Nacht und Wochenende bleiben still.

Weil die Mindestzahl je Heartbeat fest ist, bekommt jede Phase mit eigener Erwartung einen eigenen Heartbeat und eine eigene Zeile in der Crontab des Servers. Ein Muster für einen mittelgroßen Shop, die Zahlen sind Beispielwerte:

# Crontab des Shop-Servers, Zeitzone des Servers: Europe/Berlin
# Minute Stunde Tag Monat Wochentag  Befehl
5 8-21 * * 1-5   /opt/shop/count-orders.sh bestellungen-werktag-x7k2m9qa 60
5 9-22 * * 0,6   /opt/shop/count-orders.sh bestellungen-wochenende-p4n8c2tw 60
5 7 * * *        /opt/shop/count-orders.sh bestellungen-nacht-h3v6r1ze 480

Teilausfälle: wenn nur eine Zahlungsart streikt

Ein Nullalarm erkennt den Totalausfall. Häufig fällt aber nur ein Teil aus, und die Zahl sinkt, ohne null zu erreichen. Im Internet entfallen laut Zahlungstagebuch der Bundesbank 50 % der Bezahlvorgänge auf Internetbezahlverfahren (Bundesbank), es folgen Lastschriften und Überweisungen mit 30 % sowie Kreditkarten mit 15 % (Bundesbank). Fällt ein Verfahren aus, fehlt ein Anteil in dieser Größenordnung, der Rest läuft weiter. Dass Kundinnen und Kunden dann einfach die Zahlart wechseln, ist nicht ausgemacht: Für 54 Prozent der Befragten sind die Zahlungsmöglichkeiten bei der Auswahl eines Online-Shops sehr wichtig (Bitkom).

Für Teilausfälle gibt es zwei Wege. Eine höhere Mindestzahl greift nur, wenn das Fenster genug Bestellungen enthält, damit der Ausfall eines Drittels sich vom Zufall abhebt, und sie erhöht die Zahl der Fehlalarme. Genauer ist ein eigener Heartbeat je Zahlungsart: Der Zähljob filtert nach der Zahlungsart und meldet jede an ihren eigenen Heartbeat, wobei die Faustregel je Zahlungsart gilt. Welche Zahlungsarten im eigenen Shop welchen Anteil haben, zeigt der Beitrag Zahlungsarten auswerten.

• Je Shop oder Domain, wenn ein System mehrere Länder oder Marken bedient. Fällt nur die österreichische Kasse aus, bleibt die Gesamtzahl unauffällig.
• Je Verkaufskanal, etwa eigener Shop, B2B-Portal und Marktplatz-Importe. Ein hängender Import sieht in der Summe aus wie ein ruhiger Tag.
• Je Bestellweg, wenn Bestellungen auch über eine App oder Schnittstelle eingehen.
• Nicht je Artikel oder Kategorie. Dort ist λ in der Regel zu klein, und die Alarme werden zu Rauschen.

Bestell-Heartbeat, Analytics-Alarm und Browser-Test im Vergleich

Der Bestell-Heartbeat ist nicht die einzige Möglichkeit, einen Kassenausfall zu bemerken. Drei Verfahren ergänzen sich, weil sie an verschiedenen Stellen messen. Ein Browser-Monitoring mit Checkout-Ablauf klickt sich regelmäßig durch den Kaufprozess und sieht einen Defekt ohne echten Kaufverkehr, in der Regel aber nur bis vor die echte Zahlung; wie solche Abläufe aufgebaut werden, zeigt der Beitrag zum Login-Flow und Checkout. Die Analytics-Alarme der cookielosen Analytics werten stündlich aus, was der Tracker auf der Bestellbestätigung gezählt hat, mit fester Schwelle oder als Rückgang gegenüber demselben Zeitfenster eine Woche zuvor. Der Bestell-Heartbeat zählt in der Datenbank selbst.

Aufschlussreich wird es, wenn zwei Verfahren nicht übereinstimmen. Meldet der Analytics-Alarm einen Einbruch, während der Heartbeat normale Zahlen sieht, hat die Bestätigungsseite oder das Tracking ein Problem. Fallen beide, ist der Verkauf selbst betroffen. Bleibt nur der Heartbeat aus, liegt der Fehler beim Zähljob oder seinem Server. Auf ungewöhnliche Abweichungen weisen zusätzlich automatische Auswertungen hin, wie der Beitrag zur Anomalie-Erkennung beschreibt.

Wenn der Alarm kommt: die ersten Schritte

Ein Bestell-Alarm sagt, dass etwas nicht stimmt, nicht was. Zuerst wird der Befund bestätigt und eingegrenzt, idealerweise in einer festen Reihenfolge, die in der Bereitschaft griffbereit liegt:

1. Testbestellung auslösen, mit einer stornierbaren Zahlungsart. Scheitert sie, ist der Befund bestätigt, und die Fehlermeldung im Browser ist oft der wichtigste Hinweis.
2. Zahlungsarten einzeln prüfen. Läuft Rechnungskauf, aber keine Kartenzahlung, liegt das Problem beim Zahlungsmodul oder Zahlungsdienst.
3. Änderungen der letzten Stunden ansehen: Deploy, Plugin-Update, neue Preis- oder Versandregel. Wie ein Rollback mit Nachmessung abläuft, beschreibt der Beitrag zu Deploy-Fehlern als Ausfallursache.
4. Fehlerprotokoll und Rückmeldungen des Zahlungsdienstes prüfen. Abgewiesene Rückmeldungen erklären Bestellungen, die angelegt, aber nicht bestätigt wurden.
5. Nach der Behebung zählen lassen. Der nächste Lauf mit ausreichender Zahl löst den Alarm automatisch auf; wer nicht warten will, startet den Zähljob von Hand.

Wer den Alarm um 20 Uhr an einem Aktionstag bekommt und wer übernimmt, wenn niemand reagiert, sollte vorher feststehen. Wie sich Schwellen und Kanäle so einstellen lassen, dass Alarme ernst genommen werden, beschreibt der Beitrag zur Alarm-Fatigue. Dauert eine Störung länger, hilft eine kurze Notiz auf der Statusseite, bevor die ersten Kundenmails eintreffen.

Vor der Black Week einrichten, nicht in der Black Week

Zu Black Friday und Cyber Monday 2025 rechnete der Handelsverband mit 5,8 Milliarden Euro Umsatz (HDE), und laut einer Umfrage im Auftrag des Verbands nutzen 54 Prozent der befragten Online-Shopper den Black Friday auch für Weihnachtseinkäufe (HDE). Wer eine neue Überwachung erst in dieser Woche scharf schaltet, lernt ihre Fehlalarme in der Woche kennen, in der am wenigsten Zeit dafür bleibt. Besser ist ein Vorlauf:

1. Vier Wochen vorher: Bestellungen je Stunde und Wochentag auswerten, λ je Phase bestimmen, Fenster und Mindestzahlen festlegen.
2. Drei Wochen vorher: Zähljob einrichten, Zählung mit der Bestellübersicht abgleichen, Heartbeats mit Cron-Plan und Zeitzone anlegen.
3. Zwei Wochen vorher: Gegenprobe mit items=0 von Hand. Kommt der Alarm im richtigen Kanal bei der richtigen Person an? Danach ein gesunder Ping, der Alarm muss sich auflösen.
4. Vor den Aktionstagen: Bei deutlich höherer Bestellrate einen zusätzlichen Heartbeat mit höherer Mindestzahl anlegen, den der Cron-Plan nur an diesen Tagen erwartet, etwa 5 8-23 27-30 11 * für den 27. bis 30. November.
5. Nach der Black Week: Jeder Fehlalarm weist auf ein zu kurzes Fenster oder eine zu hohe Mindestzahl hin.

Wie die Website selbst durch diese Wochen kommt, steht im eingangs verlinkten Beitrag zu den Lastspitzen. Wer seine Aktionsseite jedes Jahr unter derselben Adresse führt, hat auch für den Uptime-Check eine feste Adresse, siehe Black-Friday-Seite mit fester URL. Dieselbe Technik überwacht auch Sicherungsläufe, wie der Beitrag zum Backup-Monitoring mit Heartbeats zeigt.