Produktfeed überwachen: Leere oder veraltete Exporte finden

Warum ein Produktfeed still ausfällt

Für viele Händler ist der Feed die Verbindung zu Kanälen, die einen großen Teil der Reichweite tragen. In einer repräsentativen Befragung gaben 85 Prozent der Online-Shopper an, häufig auf großen Online-Marktplätzen einzukaufen, und 21 Prozent kaufen über Vergleichsportale (Bitkom). Befragt wurden 1.120 Internetnutzende ab 16 Jahren in Deutschland, darunter 1.072 Online-Shopper (Bitkom). Auf der Seite der Anbieter verkauften 45 Prozent der EU-Unternehmen mit Webverkäufen über einen Online-Marktplatz (Eurostat); gezählt sind Unternehmen ab zehn Beschäftigten (Eurostat), Bezugsjahr 2024.

Der Feed selbst ist dabei unscheinbar. Ein geplanter Job liest die Artikel aus der Shop-Datenbank, schreibt eine XML- oder Textdatei und legt sie unter einer Adresse ab, die das Portal in seinem eigenen Takt abholt. Zwischen Datenbank und Portal liegen damit mehrere Schritte, und jeder kann ausfallen, ohne dass es auf der Website auffällt:

• Der Job startet nicht. Ein geänderter Crontab oder ein Umzug auf einen neuen Server ohne den Zeitplan, und der Export bleibt aus.
• Der Job läuft, findet aber nichts. Ein Filter auf eine umbenannte Kategorie oder eine Abfrage, die nach einem Update leer bleibt, erzeugt eine Datei mit Kopf und ohne Artikel.
• Der Job bricht ab. Speicher, Zeitlimit oder ein einzelner fehlerhafter Datensatz beenden den Lauf mittendrin. Zurück bleibt eine halbe Datei oder die alte.
• Die Datei wird nicht ersetzt. Fehlende Schreibrechte oder ein voller Datenträger, und unter der Feed-URL liegt weiter die Fassung vom Vortag.
• Die URL liefert etwas anderes. Eine Wartungsseite, eine Anmeldeseite oder eine Fehlerseite steht dort, wo das Portal eine Datei erwartet.
• Ein Cache liefert eine alte Fassung. Die neue Datei liegt auf dem Server, ausgeliefert wird eine ältere Kopie.

Gemeinsam ist allen Fällen, dass die übliche Erreichbarkeitsprüfung grün bleibt. Die Website antwortet, und auch die Feed-URL antwortet oft mit Status 200, nur eben mit dem falschen Inhalt. Das Muster kennen Sie aus dem Beitrag über stille Ausfälle von Cron-Jobs: Wer nur von außen fragt, sieht den Prozess dahinter nicht.

Die 30-Tage-Frist ist kein Alarm

Wie lange ein Portal mit einem stehenden Export weiterarbeitet, legt das Portal fest. Für Google beschreibt die Hilfe zum Merchant Center eine feste Grenze: Artikel laufen 30 Tage nach der letzten Aktualisierung ab (Google Merchant Center Help). Die Grenze gilt für Artikel, die aus einer Datenquelle wie einer Feed-Datei stammen; direkt im Merchant Center angelegte Artikel laufen laut derselben Seite nicht ab (Google Merchant Center Help).

Aktualisiert werden Artikel, indem die Datenquelle erneut eingereicht oder per Zeitplan regelmäßig hochgeladen wird (Google Merchant Center Help). Zusätzlich prüft Google die Website selbst und frischt Artikel automatisch auf, wenn sich die Produktdaten bestätigen lassen, etwa über strukturierte Daten nach schema.org auf den Produktseiten (Google Merchant Center Help). Setzt der Feed für einen Artikel ein eigenes Ablaufdatum, gilt das frühere von beiden: das gesetzte Datum oder 30 Tage nach der letzten Aktualisierung (Google Merchant Center Help).

Für die Überwachung folgt daraus vor allem eines: Auf den Ablauf zu warten, ist kein Plan. Ob eine unveränderte Datei bei jeder geplanten Abholung als Aktualisierung zählt, sagt die Hilfeseite nicht ausdrücklich. Steht der Export und die Feed-URL liefert weiter die alte Datei, kann ein Portal sie tagelang abholen, ohne dass etwas abläuft. Preise, Bestände und neue Artikel bleiben dann auf dem Stand des letzten erfolgreichen Laufs. Liefert die URL gar nichts mehr, bleibt die Aktualisierung aus, doch bis die Frist endet, vergehen Wochen. Als Warnung kommt der Ablauf damit zu spät.

Drei Stellen, an denen ein Feed scheitert

Ordnet man die Fehlerbilder, bleiben drei Stellen: der Exportjob, der die Datei erzeugt, die Datei selbst mit ihrer Artikelzahl und die Adresse, unter der das Portal abholt. Für jede Stelle gibt es ein eigenes Signal. Die Tabelle zeigt, welches Fehlerbild welches Signal auslöst und wo nur noch das Portal selbst weiterhilft.

Die ersten fünf Zeilen deckt der Heartbeat ab, weil er im Job selbst sitzt. Die beiden folgenden deckt der API-Check ab, weil er dieselbe Adresse abruft wie das Portal. Die letzten beiden bleiben für beide unsichtbar; dazu mehr im Abschnitt über die Grenzen.

Der Exportjob meldet sich mit der Artikelzahl

Ein Heartbeat dreht die Prüfung um: Nicht ein Prüfer fragt von außen, sondern der Job meldet sich nach jedem Lauf. Bleibt die Meldung aus, gibt es einen Alarm. Beim Bestell-Heartbeat zählt ein kleiner Job die Bestellungen der letzten Stunde. Beim Feed zählt der Exportjob, was er gerade geschrieben hat, und das ist der entscheidende Unterschied: Gezählt wird in der fertigen Datei, nicht in der Datenbank. Nur so fällt auf, wenn die Abfrage stimmt, aber beim Schreiben etwas verloren geht.

#!/usr/bin/env bash
# Erzeugt den Produktfeed, prüft ihn und meldet das Ergebnis an einen Heartbeat.
# Aufruf: feed-export.sh <heartbeat-slug> <mindestzahl>
set -uo pipefail

HB="https://api.xictraq.com/api/heartbeat/$1"
MIN="${2:-1}"
TARGET="/var/www/shop/public/feeds/products.xml"
TMP="$TARGET.new"   # Zwischendatei im selben Verzeichnis

# Beginn melden: XICTRAQ® rechnet daraus die Laufzeit.
curl -fsS -m 10 "$HB/start" >/dev/null || true

# Platzhalter für den Exportbefehl Ihres Shopsystems.
/opt/shop/bin/feed-export --format=xml --output="$TMP"
RC=$?

# Gezählt wird in der geschriebenen Datei, nicht in der Datenbank.
N=0
if [ -s "$TMP" ]; then
  N=$(grep -o '<item>' "$TMP" | wc -l)
fi

# Nur eine plausible Datei ersetzt die ausgelieferte, und zwar in einem Schritt.
if [ "$RC" -eq 0 ] && [ "$N" -ge "$MIN" ]; then
  mv -f "$TMP" "$TARGET"
fi

# Ergebnis melden, auch wenn die neue Datei verworfen wurde.
curl -fsS -m 10 "$HB/ping?exit_code=${RC}&items=${N}" >/dev/null

Drei Stellen tragen das Skript. Der Aufruf von /start hält den Beginn fest, damit XICTRAQ® die Laufzeit selbst ausrechnet, sobald der abschließende Ping kommt. Der Export schreibt in eine Zwischendatei im selben Verzeichnis, und erst wenn Exit-Code und Artikelzahl stimmen, ersetzt mv die ausgelieferte Datei. Innerhalb eines Dateisystems ist das ein Umbenennen, bei dem der Name während des Vorgangs entweder auf die alte oder auf die neue Datei zeigt (POSIX). Ein Portal, das genau in diesem Moment abholt, bekommt also keine halbe Datei.

Die letzte Zeile meldet beides an den Heartbeat: den Exit-Code des Exports und die gezählten Artikel. Gemeldet wird auch dann, wenn die neue Datei verworfen wurde. Genau dieser Ping mit items=0 oder einem Fehlercode löst den Alarm aus, während das Portal weiter die letzte gute Fassung abholt. Was ein Portal mit einer leeren Datei anfangen würde, legt das Portal fest; sicherer ist es, eine leere oder zu kurze Datei gar nicht erst auszuliefern.

Bei Textdateien mit Tabulatoren zählt wc -l die Zeilen, die Kopfzeile wird abgezogen. Bei XML zählt das Skript die Artikelelemente; je nach Format heißen sie <item> oder <entry>. Welche weiteren Parameter ein Ping tragen kann, etwa eine kurze Notiz über msg, beschreibt die Heartbeat-Dokumentation.

Zeitplan, Mindestzahl und Laufzeit einstellen

Am Heartbeat entscheiden wenige Einstellungen, wann ein Lauf als gestört gilt. Die Tabelle zeigt sie für einen Export, der jede Nacht um 02:15 startet und üblicherweise acht Minuten braucht.

Der Zeitplan beschreibt, wann der Export startet. XICTRAQ® rechnet vom letzten Ping aus den nächsten Termin des Zeitplans; bis zu diesem Termin plus Toleranz muss der nächste Ping eintreffen. Startet der Export um 02:15, gehört 02:15 in den Heartbeat, und die Toleranz deckt die Laufzeit samt Schwankung ab. Stünde dort die Endzeit 02:25, wäre nach einem Ping um 02:23 schon 02:25 desselben Tages der nächste Termin, und ab 02:55 käme ein Alarm, obwohl der Export gelaufen ist. Die Toleranz lässt XICTRAQ® zwischen 0 und 3600 Sekunden zu, also höchstens eine Stunde (XICTRAQ®-Dokumentation). Bleibt der Ping bis zum Termin plus Toleranz aus, folgt der Alarm. Sinnvoll ist ein Abstand zur Abholung durch das Portal: Ohne eigene Einstellung holt das Merchant Center eine verlinkte Datei alle 24 Stunden ab (Google Merchant Center Help), Häufigkeit und Uhrzeit lassen sich im Zeitplan der Datenquelle wählen (Google Merchant Center Help). Liegt die Abholung einige Stunden nach dem Export, bleibt nach einem Alarm Zeit, den Lauf von Hand zu wiederholen.

Die Mindestzahl ist ein fester Wert je Heartbeat. XICTRAQ® vergleicht die gemeldete Zahl mit ihr; eine Erwartung, die sich selbst an den Verlauf anpasst, gibt es für die Artikelzahl nicht. Ein brauchbarer Ausgangswert ist der niedrigste normale Lauf der letzten Wochen, abzüglich eines Puffers für übliche Schwankungen. Die Zahlen je Lauf zeigt der aufklappbare Verlauf am Heartbeat. Ändert sich das Sortiment deutlich, etwa zum Saisonwechsel, wird die Mindestzahl mit angepasst. Wer zusätzlich expect_output einschaltet, bekommt bei items=0 auch dann einen Alarm, wenn keine Mindestzahl gesetzt ist.

Die Feed-URL prüfen: was das Portal vorfindet

Der Heartbeat beweist, dass der Job gelaufen ist. Ob die Datei unter der Adresse ankommt, die das Portal abruft, beweist er nicht. Dafür gibt es den API-Check: Er ruft die Feed-URL im eingestellten Takt ab und prüft die Antwort gegen feste Erwartungen. Drei davon passen zum Feed:

1. Status. Erwartet wird ein Status zwischen 200 und 299. Der Status 200 besagt, dass die Anfrage erfolgreich war (RFC 9110); über den Inhalt sagt er nichts.
2. Antwortzeit. Eine Schwelle deutlich über dem Normalwert zeigt, wenn der Server die Datei nur noch zäh ausliefert. Den Normalwert liest man vorher mit „Jetzt prüfen“ ab.
3. Inhalt. Eine Text-Assertion sucht eine Zeichenfolge, die nur in einem echten Feed steht, etwa das Element <item> oder bei Textdateien den Anfang der Kopfzeile.

[
  { "type": "status_code", "operator": "in_range", "value": "200-299" },
  { "type": "response_time_ms", "operator": "lt", "value": 5000 },
  { "type": "text_contains", "value": "<item>" }
]

Die dritte Erwartung ist die wichtigste. Die Hilfe zum Merchant Center verlangt, dass die Adresse direkt auf die Datei zeigt; zeigt sie auf eine HTML-Seite der Website, scheitert die Verarbeitung (Google Merchant Center Help). Genau das passiert, wenn während eines Updates eine Wartungsseite mit Status 200 ausgeliefert wird oder eine Weiterleitung auf die Anmeldung zeigt. Der Statuscheck ist dann grün, die Text-Assertion nicht. Wie eine Wartungsseite den passenden Status setzt, steht im Beitrag zu Wartungsfenstern mit 503 und Retry-After.

Zwei Hinweise zur Einrichtung. Eine Feed-Datei darf im Merchant Center bis zu 4 GB groß sein (Google Merchant Center Help), und bei sehr großen Antworten wertet der Check nur den Anfang aus. Die gesuchte Zeichenfolge sollte deshalb früh in der Datei stehen; ob alle Artikel drin sind, zählt der Heartbeat, nicht der API-Check. Ist die Feed-URL per Passwort geschützt, trägt der Check die Anmeldung als Kopfzeile mit. Wie man Schwellen für Antwortzeit und Status setzt, vertieft der Beitrag zu Assertions und Schwellenwerten. API-Checks sind ab dem Starter-Plan enthalten, den Überblick gibt die Preisseite.

Veraltet trotz grünem Abruf: das Alter der ausgelieferten Datei

Ein Fall fällt durch beide Signale: Der Export läuft sauber, der Heartbeat ist grün, die Feed-URL antwortet mit einem gültigen Feed, aber es ist der Feed von vorgestern. Das passiert, wenn ein Cache die Datei länger hält als gedacht oder wenn der Export in ein anderes Verzeichnis schreibt als das, aus dem der Webserver ausliefert. Welche Fassung ankommt, verrät das Kopffeld Last-Modified: Es nennt den Zeitpunkt, zu dem die Datei nach Einschätzung des Servers zuletzt geändert wurde (RFC 9110). Wie lange ein Cache eine Antwort als frisch behandelt, steuert unter anderem die Angabe max-age (RFC 9111). Mehr zu diesen Fallen steht im Beitrag über veraltete Inhalte nach dem Deploy.

Der API-Check vergleicht feste Erwartungen und rechnet kein Alter aus. Ein zweiter Heartbeat kann es: Ein kleines Skript auf einem anderen Rechner holt die Datei so ab, wie ein Portal es tut, liest das Alter aus Last-Modified, zählt die Artikel in der ausgelieferten Fassung und meldet beides. Ist die Datei älter als erlaubt, meldet es einen Fehlschlag mit Grund.

#!/usr/bin/env bash
# Holt den Feed ab wie ein Portal und meldet Alter und Artikelzahl an einen zweiten Heartbeat.
# Aufruf: feed-delivery-check.sh <heartbeat-slug> <feed-url> <max-alter-in-stunden>
set -uo pipefail

HB="https://api.xictraq.com/api/heartbeat/$1"
URL="$2"
MAX_HOURS="${3:-26}"
TMP=$(mktemp)
trap 'rm -f "$TMP"' EXIT

fail() { curl -fsS -m 10 --get --data-urlencode "msg=$1" "$HB/fail" >/dev/null; exit 1; }

HEADERS=$(curl -fsSL -m 120 -D - -o "$TMP" "$URL") || fail "Abruf fehlgeschlagen"

LAST_MODIFIED=$(printf '%s\n' "$HEADERS" | tr -d '\r' \
  | awk -F': ' 'tolower($1)=="last-modified" {v=$2} END {print v}')
[ -n "$LAST_MODIFIED" ] || fail "Kein Last-Modified in der Antwort"

AGE_HOURS=$(( ( $(date +%s) - $(date -d "$LAST_MODIFIED" +%s) ) / 3600 ))
[ "$AGE_HOURS" -le "$MAX_HOURS" ] || fail "Ausgelieferte Datei ist ${AGE_HOURS} Stunden alt"

N=$(grep -o '<item>' "$TMP" | wc -l)
curl -fsS -m 10 "$HB/ping?items=${N}" >/dev/null

Läuft das Skript stündlich, schlägt es an, sobald die ausgelieferte Datei älter ist als ein Exportzyklus plus Puffer. Weil es von außen abholt, deckt es auch Cache, Weiterleitung und falsches Verzeichnis ab. Den Heartbeat im Exportjob ersetzt es nicht: Der meldet Fehlercode und Laufzeit, die nur der Job selbst kennt.

Was die Überwachung nicht sieht

Heartbeat und API-Check prüfen, ob ein Feed entsteht, wie viele Artikel er trägt und ob er abholbar ist. Den Inhalt einzelner Artikel prüfen sie nicht. Vier Lücken bleiben:

• Veraltete Preise und Bestände. Ein Export kann pünktlich laufen und trotzdem falsche Werte schreiben, etwa wenn er seine Preise aus einer anderen Quelle liest als der Shop. Das zeigt erst der Abgleich mit der Produktseite.
• Abgelehnte Artikel. Fehlende Pflichtangaben, ungültige Kennungen oder Verstöße gegen Richtlinien meldet das Portal in seiner eigenen Fehlerliste.
• Gesperrte Abrufer. Die Hilfe zum Merchant Center verlangt, die Kennungen „Googlebot“ und „AdsBot-Google“ für das Verzeichnis der Datenquelle nicht zu sperren (Google Merchant Center Help). Eine zu strenge Bot-Abwehr sperrt womöglich genau diese Abrufer, während der API-Check mit seiner eigenen Kennung durchkommt.
• Schleichender Schwund. Die Mindestzahl ist eine feste Untergrenze. Fällt die Artikelzahl etwa von 4.800 auf 4.100, bleibt das über einer Mindestzahl von 4.000 ohne Alarm. Einen Einbruch gegenüber dem Vortag erkennt der Heartbeat nicht.

Für diese Lücken bleibt der Blick in die Diagnose des Portals Pflicht, idealerweise in einem festen Rhythmus, etwa jeden Montag. Ähnlich still kann im Shop selbst die Suche ausfallen, ohne dass eine Seite einen Fehler zeigt; wie man das prüft, zeigt der Beitrag zur Überwachung der Shopsuche.

Mehrere Feeds, mehrere Empfänger

Viele Shops erzeugen nicht einen Feed, sondern mehrere: einen für Shopping-Anzeigen, einen für Preisvergleiche, einen je Marktplatz, oft in verschiedenen Formaten und mit eigenem Zeitplan. Jeder Feed bekommt einen eigenen Heartbeat und, wenn er unter einer eigenen Adresse abgeholt wird, einen eigenen API-Check. Ein Namensschema mit Kanal und Takt, etwa „Feed Preisvergleich nachts“, hält die Alarmliste lesbar. Heartbeats haben ein eigenes Kontingent je Plan, unabhängig von der Zahl der Websites.

Wohin die Meldung geht, legen die Alarmkanäle fest: E-Mail, Slack, Teams, Discord, Telegram oder Webhook. Ein Feed-Alarm um 03:00 nützt nur, wenn ihn morgens die richtige Person liest. Ob die Kette bis zum Telefon trägt, lässt sich vorher in einer Alarmierungsübung prüfen.

Feed-Überwachung vor den Aktionswochen einrichten

Die Wochen vor Black Friday sind eine schlechte Zeit für einen stehenden Feed. In der Befragung zum Black Friday 2025 wollte rund jede und jeder Zweite (52 Prozent) die reduzierten Preise nutzen, die allermeisten online (Bitkom). Wer Aktionspreise zeitgesteuert ändert, braucht einen Feed, der Schritt hält; ein Feed vom Vortag zeigt im Portal sonst einen Preis, den der Shop nicht mehr führt. Die Einrichtung ist überschaubar:

• Je Feed einen Heartbeat mit Cron-Ausdruck, Zeitzone und Toleranz anlegen.
• Exportskript auf Zwischendatei, Prüfung und Umbenennen umstellen, Ping mit exit_code und items.
• Mindestzahl aus den letzten Läufen ableiten und expect_output einschalten.
• Feste Laufzeitschwelle deutlich über die übliche Laufzeit setzen.
• Je Feed-URL einen API-Check mit Status, Antwortzeit und Text-Assertion anlegen.
• Optional ein Auslieferungsskript mit Prüfung von Last-Modified als zweiten Heartbeat einrichten.
• Abholung im Portal mit einigen Stunden Abstand hinter den Export legen.
• Gegenprobe: einen Ping mit items=0 von Hand senden und den Alarm im Kanal abwarten.

Die Gegenprobe ist der wichtigste Punkt der Liste. Erst wenn ein künstlicher Leerlauf einen Alarm auslöst, der beim Empfänger ankommt, ist die Überwachung mehr als eine Einstellung. Der nächste gesunde Ping des echten Jobs hebt den Alarm wieder auf.

Den Feed als Prozess überwachen, nicht als Datei

Ein Produktfeed fällt selten laut aus. Er wird leer, alt oder unvollständig, während Shop und Startseite normal arbeiten. Wer ihn als Prozess überwacht, mit einer Meldung aus dem Exportjob, einer Prüfung der Adresse und einem Blick auf das Alter der ausgelieferten Datei, erfährt davon am selben Morgen und nicht erst aus dem Portal. Dasselbe Prinzip trägt bei Sicherungsläufen und bei jedem anderen Job, dessen Ergebnis eine Datei ist. Einrichten lässt sich beides mit den Heartbeats von XICTRAQ® und dem API-Monitoring im selben Konto.