Sechs Regeln für einen Sync, der läuft, während niemand zusieht

Am 8. Oktober 2026 veröffentlichten Lance Martin und CJ Avilla eine Anleitung zu einem Agenten, der jeden Morgen Slack und GitHub liest und eine Zusammenfassung in Slack postet. Niemand sieht ihm beim Laufen zu. Ihr nützlichster Absatz handelt von einem Fehler, der wie Erfolg aussieht. Wenn der Server einer Quelle ausgefallen oder ihr Token abgelaufen ist, „sieht der Agent nichts von dieser Quelle und meldet ‚nichts Neues‘“.

Ein Shopify-zu-Brevo-Kontakt-Sync hat denselben Fehler. Genauso wie jeder geplante Sync zwischen zwei SaaS-Tools. Ein Lesevorgang, der still scheitert, sieht genau aus wie ein Shop, in dem sich heute niemand angemeldet hat.

Ihr Artikel endet mit sechs Regeln für einen Agenten, der unbeaufsichtigt läuft. Lies sie als jemand, der Syncs betreibt, und jede davon ist eine Regel für Reverse ETL. Der Worker ist ausgefallen. Der Sync nicht. verfolgt einen Kontakt durch einen Absturz. Diese Seite ist die Checkliste darüber: sechs Regeln für eine automatisierte Datensynchronisierung, was Tajos Runner heute bei jeder davon tut und wo er zu kurz greift. Die Seite des Runners steht in Eine hängende oder fehlgeschlagene Synchronisierung wiederherstellen.

1. Lies von einem Lesezeichen und bewege es erst, wenn der Batch angekommen ist

Ihre erste Regel: „Lies jede Quelle von einem Lesezeichen, nicht aus einem festen Zeitfenster.“ Ein Fenster wie „die letzten 24 Stunden“ hinterlässt eine Lücke, wenn ein Lauf zu spät startet, und wiederholt Datensätze, wenn er zu früh startet.

Ein Tajo-Sync liest seine Quelle in Batches ab einem gespeicherten Cursor. Der Cursor bewegt sich am Ende eines Batches, und nur, wenn jeder Datensatz in diesem Batch angekommen ist. Ein Lauf, der scheitert, behält die letzte saubere Position, sodass der nächste Lauf den unterbrochenen Batch erneut liest, statt ihn zu überspringen.

Bestellungen bekommen ein eigenes Lesezeichen. Ein geplanter Shopify-Bestellungs-Sync beginnt mit seinem ersten geplanten Lauf und sendet, was sich seit dem vorherigen geändert hat. Vergangene Bestellungen gehen nur raus, wenn eine Person den Sync ausführt. Geplante Läufe und Läufe, die eine Person startet, haben getrennte Cursor, sodass ein Nachladen der Historie oder ein Test-Batch den geplanten nicht zurückspulen kann.

Der Preis: Ein unterbrochener Batch wird zweimal gelesen. Regel 2 macht das sicher.

2. Gib jedem Schreibvorgang einen Schlüssel, der den Absturz überlebt

Ihre vierte Regel zählt einen Post erst als gesendet, „wenn Slack ihn bestätigt“, und aktualisiert erst dann Lesezeichen und Ledger. Ein Einschreiben funktioniert so. Es ist zugestellt, wenn der unterschriebene Rückschein zurückkommt, nicht wenn es den Schalter verlässt.

Bevor Tajo einen Datensatz schreibt, bekommt der Datensatz einen Zustellschlüssel. Der Schlüssel ist ein Hash aus dem Sync, der Quelle, dem Seiten-Cursor, der Position auf der Seite und dem Datensatz selbst, er enthält also keine personenbezogenen Daten. Er wird beansprucht, bevor das Ziel aufgerufen wird, und als abgeschlossen markiert, wenn der Schreibvorgang gelingt. Abgeschlossene Schlüssel werden sieben Tage lang aufbewahrt. Eine Wiederholung oder ein späterer geplanter Lauf leitet für denselben Datensatz denselben Schlüssel ab, findet ihn abgeschlossen und ruft das Ziel nicht erneut auf.

Das hat zwei Preise. Nach sieben Tagen vergisst das Ledger, und ein erneutes Abspielen ab einem älteren Cursor kann wieder schreiben. Und ein Schreibvorgang mit Zeitüberschreitung hinterlässt einen ehrlichen Zweifel: Das andere System hat ihn vielleicht gespeichert, ohne zu antworten. Tajo versucht diesen Schreibvorgang bei einem späteren Versuch erneut, statt ihn sieben Tage lang als gescheitert zu verbuchen. Ein Connector, der dem Ziel einen eigenen Idempotenzschlüssel übergibt, schließt diesen Zweifel. Einer, der das nicht kann, bleibt mit der Möglichkeit eines Duplikats zurück.

3. Ein Lauf besitzt den Sync und weist das vor jedem Schreibvorgang nach

Ihre dritte Regel: „Prüfe jedes Element direkt vor dem Posten erneut.“ Bei einem Sync ist das, was sich zwischen Lesen und Schreiben am ehesten geändert hat, die Frage, wer schreiben darf.

Jeder Tajo-Sync hat ein Lease, mit eigenem Token und einer Lebensdauer von 15 Minuten, die alle fünf Minuten verlängert wird. Ein Lauf prüft, dass er das Lease noch hält, bevor er das Ziel aufruft, und noch einmal, bevor er den Cursor bewegt. Ein Lauf, der es verloren hat, stoppt, und seine Seite zeigt „Der Lauf hat seinen Slot unterwegs verloren und gestoppt, um nicht doppelt zu schreiben.“ Ein zweiter Lauf, der mit einem laufenden kollidiert, endet, statt sich dahinter einzureihen.

Auch Datensätze werden geprüft. Zwischen Lesen und Schreiben laufen Datensätze durch den Einwilligungsfilter. Ein Kontakt, der ohne nachweisbare Einwilligung in eine Marketing-Zielgruppe geschrieben würde, wird abgelehnt statt erraten. In den Worten der Hilfeseite ist der Fehlermodus „zu vorsichtig“, nie „zu viel gesendet“.

4. Wiederhole, was vorübergeht, stoppe, was bleibt

Ihre sechs Regeln sagen nichts darüber, wie oft man es erneut versucht. Ein Sync braucht diese Regel, denn seine häufigsten Fehler sind ein Rate Limit und eine schlechte Minute beim Anbieter.

Ein Tajo-Lauf aus der Warteschlange, der scheitert, bekommt fünf Versuche. Die Wartezeiten dazwischen betragen 60, 120, 240 und 480 Sekunden, insgesamt etwa fünfzehn Minuten. Manche Fehler werden nie wiederholt, weil ein erneuter Versuch sie nicht beheben kann. Ein Lauf, der mit einem bereits laufenden kollidiert ist, wird nicht wiederholt, und ebenso wenig ein Lauf, dessen veröffentlichte Version oder Verbindungen nicht mehr gültig sind.

Eine Serie ist etwas anderes als ein Ausrutscher. Wenn die letzten fünf beendeten Läufe seit der letzten Änderung des Syncs alle gescheitert sind, pausiert Tajo den Sync und zeigt den letzten Fehler auf seiner Seite. Ein Erfolg setzt die Zählung zurück. Nichts startet einen pausierten Sync von selbst neu; eine Person behebt die Ursache und veröffentlicht ihn erneut. Der Artikel über den ausgefallenen Worker erzählt den Vorfall, aus dem diese Regel entstand.

5. Behandle Stille als Befund

„Melde einen gescheiterten Lesevorgang als unlesbar, nie als ruhigen Tag.“ Das ist die schwerste der sechs Regeln, und die, die wir nur teilweise erfüllen.

Wo sie greift: Ein Lesevorgang mit Fehler lässt den Lauf scheitern. Ein abgelehntes Token oder ein Server, der nicht antwortet, sendet nichts an das Ziel, lässt den Cursor, wo er war, und zählt zur Pause nach fünf gescheiterten Läufen. Und jede Stunde, um 13 Minuten nach, prüft Tajo jeden Workspace mit einem aktiven Sync. Es alarmiert sein eigenes Team, wenn es in den letzten 24 Stunden keinen erfolgreichen Lauf gab, auch bei einem Workspace, in dem gar kein Lauf erfasst wurde. Das ist die stündliche Prüfung.

Wo sie nicht greift: Der stille Lesevorgang, den die Autoren beschreiben, ist einer, der mit „OK“ und null Datensätzen antwortet. Unser Runner zählt das als Erfolg. Für Quellen wie Shopify-Kund:innen warnt eine separate Prüfung Tajos Team nach zehn erfolgreichen Läufen in Folge mit null Datensätzen, sofern der Sync vorher Datensätze geliefert hat. Shopify-Bestellungen werden nach Änderungszeit gelesen, ein leerer Lauf ist dort also normal, und diese Prüfung läuft nicht. Eine Quelle, die einige Datensätze liefert, aber weniger, als sie sollte, wird gar nicht erkannt.

Der Einwand lautet so: „Zehn leere Läufe sind zweieinhalb Stunden bei einem 15-Minuten-Takt. Warum nicht beim ersten alarmieren?“ Kontakt-Syncs laufen standardmäßig alle 15 Minuten. Und ein Shop ohne neue Kund:innen in einer Viertelstunde ist gewöhnlich. Ein Alarm beim ersten leeren Lauf würde jede Nacht auslösen, und einen Alarm, der immer auslöst, liest niemand. Diese Grenze tauscht Tempo gegen Glaubwürdigkeit. Sie bleibt eine Vermutung über Stille, nicht die Regel der Autoren.

6. Lege einmal fest, was der Sync schreiben darf, und lass jeden Lauf es nachweisen

Ihre fünfte Regel holt die Präferenzen des Agenten „aus einem Speicher, den der Agent nicht bearbeiten kann“. Ihre sechste gibt dem Agenten überall dort nur Lesezugriff, wo er nur liest, und begrenzt, was jeder Lauf ausgeben darf. Beide gibt es, weil der Agent Text liest, den andere geschrieben haben, und dieser Text kann versuchen, ihm Befehle zu geben.

Die Sync-Version der Präferenzdatei ist die veröffentlichte Regel. Das Veröffentlichen eines Tajo-Syncs bindet ihn an einen Digest genau der Regel, die in der Vorschau zu sehen war. Eine Bearbeitung setzt ihn auf Entwurf zurück, und er geht erneut durch die Vorschau, bevor er wieder läuft. Jeder Lauf prüft, bevor er etwas ändert, dass er genau diese veröffentlichte Version mit den Verbindungen ausführt, mit denen sie veröffentlicht wurde. Ein Lauf, der diese Prüfung nicht besteht, wird nicht wiederholt. Auch die Richtung steht fest: Eine Sync-Regel schreibt in eine Richtung und nie zurück nach Shopify.

Für die Ausgabengrenze gibt es kein Gegenstück. Unsere Sync-Läufe haben kein Ausgabenlimit pro Lauf. Das Wiederholungslimit und die Pause begrenzen, wie lange ein Fehler andauern kann, nicht, was ein Lauf kostet.

Was gebaut ist und was nicht

Gebaut, Stand heute:

• Ein Cursor, der sich erst nach einem Batch bewegt, in dem jeder Datensatz angekommen ist, und ein geplanter Bestellungs-Cursor, den von einer Person gestartete Läufe nicht zurückspulen können.
• Ein Zustellschlüssel pro Datensatz, geprüft gegen ein Ledger abgeschlossener Schreibvorgänge, das sieben Tage lang aufbewahrt wird.
• Ein Lease pro Sync, geprüft vor dem Schreibvorgang und bevor sich der Cursor bewegt.
• Fünf Versuche pro Lauf, mit Wartezeiten von 60 Sekunden und dann 120, 240 und 480, ohne Wiederholung bei einer Kollision oder einer ungültigen Veröffentlichung.
• Eine Pause, nachdem fünf Läufe in Folge gescheitert sind, angezeigt auf der Seite des Syncs.
• Ein stündlicher Alarm, wenn in den letzten 24 Stunden kein Lauf gelungen ist.
• Ein Einwilligungsfilter zur Laufzeit für Kontakte, die in eine Marketing-Zielgruppe geschrieben werden, und bei jedem Lauf eine Prüfung, dass er die veröffentlichte Version ist.

Nicht gebaut, und gut zu wissen, bevor du dich darauf verlässt:

• Ein Lesevorgang, der mit null Datensätzen gelingt, wird nicht als unlesbar gemeldet. Die Warnung nach zehn Läufen deckt einen Teil davon ab. Sie deckt keine Shopify-Bestellungen ab und keine Quelle, die zu wenige Datensätze liefert.
• Der 24-Stunden-Alarm erreicht Tajo, nicht dich, und das gilt auch für die Warnung nach zehn Läufen. Die Pause erscheint auf der Seite des Syncs.
• Die stündliche Prüfung überwacht den Workspace, nicht jeden Sync. Ein gesunder Sync verdeckt einen stillen daneben.
• Kein Ausgabenlimit pro Lauf.
• Nichts startet einen pausierten Sync neu. Das tut eine Person.
• Die Pause nach fünf Fehlern und die 24-Stunden-Prüfung gelten für die ganze Tajo-Installation, nicht pro Sync.

Wenn einer dieser Punkte bei deinem eigenen Sync auftaucht, sagt dir Eine hängende oder fehlgeschlagene Synchronisierung wiederherstellen, was du siehst und was zu tun ist.

Die Autoren schrieben sechs Regeln für eine Zusammenfassung, die eine Person jeden Morgen liest. Ein Sync hat überhaupt keine Leser:in am Morgen, deshalb braucht er sie umso mehr. Die Regeln eins bis vier und Regel sechs sind heute Code in unserem Runner. Regel fünf ist zur Hälfte geschrieben: Ein Sync, der seine Quelle nicht lesen kann, sollte das sagen.