Die meisten Integrationen in kleinen Firmen sind „unsichtbar". Sie laufen — bis sie es nicht mehr tun. Und von der Störung erfährst du nicht aus deinem System, sondern vom Kunden, der anruft und fragt, warum seine Bestellung seit drei Tagen hängt.
Das ist kein Technologie-Problem. Es ist das Problem, dass auf dem Armaturenbrett keine Kontrolllampe leuchtet. Die Integration zwischen ERP und Online-Shop, zwischen Comarch Optima und dem Versandsystem, zwischen CRM und Buchhaltungssoftware — jede davon sendet Daten leise, ohne Bestätigung. Solange die Bestätigung ausbleibt, nimmst du an „es läuft wohl schon". Und in 95% der Fälle hast du recht. Aber dieser eine Fall von zwanzig kann dich eine Woche Chaos und drei verärgerte Kunden kosten.
Bei einem unserer Kunden — einem 25-köpfigen Elektrogroßhandel in der Nähe von Posen — synchronisierten sich drei Tage lang die Lagerbestände nicht zwischen Comarch Optima und dem B2B-Portal. Die Portal-API gab brav HTTP 200 zurück, aber mit leerem Body. Kunden bestellten weiter Produkte, die seit Wochen physisch nicht auf Lager waren. Drei Tage komplette Stille, bis zum Anruf des größten Abnehmers mit der Frage „wo sind meine 400 Meter YKY-Kabel". Ein einfacher Alarm vom Typ „wenn die heutige Synchronisation 0 Datensätze zurückgegeben hat, Alarm schlagen" hätte das in 15 Minuten erfasst.
Was eigentlich schiefgehen kann
Bevor man anfängt zu überwachen, lohnt es sich zu wissen, wonach man sucht. In der Praxis gehen Integrationen auf einige wiederkehrende Arten kaputt:
- Stiller API-Fehler — die Gegenseite antwortet mit 200 OK, aber mit leerem oder falschem Body. Dein System denkt, alles ist durchgegangen.
- Formatänderung beim Anbieter — jemand beim Spediteur hat ein Feld in der Antwort ergänzt, dein Parser ist abgestürzt, der Job landet in einer Fehler-Queue, die niemand liest.
- Abgelaufenes Token / Zertifikat / Passwort — meist eine Woche später bemerkt, wenn jemand zufällig in die Logs schaut.
- Firewall-Blockade — neue IT-Richtlinie, neue IP-Adressen nach einer Migration, vergessene Whitelist.
- Volle Platte / volles Tablespace — der Job läuft los, aber es gibt keinen Platz, um das Ergebnis zu schreiben.
- Rate Limiting — die externe API gibt plötzlich 429 zurück, dein Skript versucht es endlos erneut, die Queue wächst.
- Logische Inkonsistenz — die Daten „gehen durch", ergeben aber keinen Sinn (Kunde ohne Steuernummer, Auftrag mit Preis null, Rechnung datiert auf 1970).
Jede dieser Störungen hat eine andere Signatur. Gutes Monitoring fängt alle ab, nicht nur „Server antwortet".
Drei Monitoring-Ebenen
Du brauchst kein Datadog für 2 Tsd. EUR im Monat. Du brauchst drei Ebenen, jede in einem halben Tag gebaut.
Ebene 1 — hat die Integration überhaupt gestartet. Jeder Integrations-Job sollte mit einem Eintrag enden wie „beendet um 03:17, 847 Datensätze verarbeitet". Fehlt der Eintrag, ist der Scheduler ausgefallen, der Server eingefroren oder der Job hängt. Der Alarm ist einfach: „wenn zwischen 3:00 und 3:30 kein Erfolgseintrag kommt, Mail senden". Eine Zeile im Cron, 15 Minuten Arbeit.
Ebene 2 — ergibt das, was durchgekommen ist, Sinn. Hier wird es interessant. Ein Alarm wie „wenn die heutige Synchronisation 0 Datensätze zurückgegeben hat, gestern aber 1200, Flagge hoch" fängt die meisten stillen Fehler ab. Setz auch den Gegenalarm: „wenn die heutige Synchronisation das 10-fache des 30-Tage-Durchschnitts zurückgegeben hat, Flagge hoch" — das fängt Dubletten und Endlosschleifen ab.
Ebene 3 — sind die Daten fachlich korrekt. Ein täglicher Report, der zum Beispiel prüft, dass jede Shop-Bestellung der letzten 24 h ein entsprechendes Dokument im ERP hat und jede ERP-Rechnung einen fiskalisierten Beleg. Ein einfaches Skript, das zwei Datenbanken nach Auftrags-ID vergleicht, läuft um 6:00. Ist die Mismatch-Liste leer — bleibt es still. Hat sie auch nur einen Datensatz — Mail an zwei Personen.
Zusammen fangen die drei Ebenen ungefähr 90% der realen Störungen ab, die wir in der Praxis sehen. Der Rest ist höhere Schule — und meist für Firmen mit 10–50 Mitarbeitern nicht relevant.
Alarme, die wirklich jemand liest
Der größte Fehler beim Einführen von Monitoring: Alarme produzieren, die nach einer Woche niemand mehr liest. Dann kommt die Störung, die Mail landet im Ordner mit 400 anderen, und niemand sieht sie.
Ein paar Regeln, die die Lage retten:
- Eine Störung = eine Mail pro Tag, nicht hundert. Wenn die Integration nachts 50-mal ausfällt, sende nicht 50 Mails. Eine Mail um 7:00 mit „50 Fehler zwischen 23:00 und 06:00, erster um X, letzter um Y" genügt.
- Der Alarm muss sagen, was kaputt ist und was zu tun ist. „Allegro-Integration — seit 2 Stunden keine Antwort, Token wahrscheinlich abgelaufen (letztes Mal: 2026-07-12). Erneuern im Allegro-Panel: Konto → API." Nicht „ERROR: 401 Unauthorized".
- Alarme gehen an zwei Personen, nicht eine. Eine Person ist im Urlaub oder krank. Zwei Personen sind das Minimum für Kontinuität.
- Eigener Kanal für Integrations-Alarme. Nicht in den Haupt-Admin-Posteingang zusammen mit Druckermonitoring kippen. Eigene Mail, eigener Teams-Kanal, eigene Ansicht.
Beim erwähnten Elektrogroßhandel sank nach Einführung dieser Regeln die durchschnittliche Zeit bis zur Erkennung einer Integrationsstörung von „einigen Tagen" (sprich: bis zur nächsten Kundenbeschwerde) auf etwa 20 Minuten. Die Kosten? Drei Tage Arbeit, keine neuen Lizenzen. Das Monitoring wurde auf SQL Server, einem Windows-Cron und einem Microsoft-365-Postfach gebaut.
Was man nicht überwachen kann
Nicht alles ist Technik. Manche Dinge brauchen einen Prozess — also einen Menschen, der einmal pro Woche auf einen bestimmten Report schaut.
Beispiele aus der Praxis: Ein Auftrag kommt ins ERP, aber der Vertriebsmitarbeiter vergisst, ihn sich zuzuweisen, und niemand ruft den Kunden an. Das System sieht hier keinen Fehler — die Daten wurden korrekt übertragen. Oder: Die Bankintegration zieht den Kontoauszug, aber 10% der Zahlungen lassen sich nicht automatisch Rechnungen zuordnen (weil Kunden Unsinn im Verwendungszweck schreiben). Das System fängt es ab, aber lösen muss es jemand von Hand.
Für solche Dinge bauen wir kein Monitoring, sondern einen kurzen, wöchentlichen Review. 15 Minuten jeden Montag: jemand (am besten jedes Mal die gleiche Person) öffnet die Reports „nicht zugeordnete Zahlungen", „Aufträge ohne zugewiesenen Vertriebler", „Rechnungen ohne Versand". Solange der Report in der Rotation ist — sind die Probleme unter Kontrolle. In dem Moment, in dem jemand aufhört, ihn zu öffnen, beginnt die Firma leise Geld zu verlieren.
Womit anfangen in deiner Firma
Nicht mit dem Kauf eines Tools. Fang mit einer Stunde, einem Blatt Papier und einer Liste aller Integrationen an, die ihr habt — auch der, „die alle vergessen haben, weil euer früherer IT-Mensch sie vor 5 Jahren eingerichtet hat".
Zu jedem Punkt auf der Liste beantwortet drei Fragen: von wo nach wo fließen die Daten, was passiert, wenn das heute für eine Woche ausfällt, wer erfährt davon und wann. Meistens stellt sich heraus, dass für die Hälfte der Integrationen die Antwort auf die dritte Frage lautet: „der Kunde, in 3–5 Tagen, per Telefon".
Das ist deine Prioritätenliste. Du fängst mit der an, deren Ausfall am meisten weh tut.
Wenn ihr durchsprechen wollt, welche Integrationen in eurer Firma zuerst überwacht werden sollten — das erste Gespräch ist kostenlos und dauert eine halbe Stunde. Wir gehen daraus mit einer kurzen Liste von „drei Dingen für den ersten Monat" heraus, selbst wenn keine Zusammenarbeit draus wird.
Eine Integration, von der niemand weiß, dass sie ausgefallen ist, ist seit Mittwoch tot. Du erfährst es nur erst am Freitag — vom Kunden.