Większość integracji w małych firmach jest „niewidzialna". Działa — do momentu, w którym nie działa. A o awarii dowiadujecie się nie z systemu, tylko od klienta, który dzwoni z pytaniem, dlaczego jego zamówienie wisi od trzech dni.
To nie jest problem technologii. To problem braku kontrolki na desce rozdzielczej. Integracja między ERP a sklepem internetowym, między Comarch Optima a systemem spedycyjnym, między CRM-em a programem księgowym — każda z nich wysyła dane cicho, bez potwierdzenia. Dopóki potwierdzenia nie ma, zakładacie, że „pewnie działa". I w 95% przypadków macie rację. Ale ten jeden przypadek na dwadzieścia potrafi kosztować tydzień chaosu i trzech zdenerwowanych klientów.
U jednego z naszych klientów — 25-osobowej hurtowni elektrotechnicznej spod Poznania — przez trzy dni nie synchronizowały się stany magazynowe między Comarch Optima a portalem B2B. API portalu zwracało grzecznie HTTP 200, ale z pustym body. Klienci składali zamówienia na produkty, których fizycznie nie było w magazynie od tygodni. Trzy dni kompletnej ciszy, aż do telefonu od największego odbiorcy z pytaniem „gdzie moje 400 metrów kabla YKY". Prosty alert typu „jeśli dzisiejsza synchronizacja zwróciła 0 rekordów, podnieś alarm" wyłapałby to w 15 minut.
Co właściwie może pójść nie tak
Zanim zaczniemy monitorować, warto wiedzieć, czego szukamy. W praktyce integracje padają na kilka powtarzalnych sposobów:
- Cicha awaria API — druga strona odpowiada 200 OK, ale z pustym albo błędnym body. Nasz system myśli, że wszystko poszło.
- Zmiana formatu po stronie dostawcy — ktoś w firmie kurierskiej dodał pole do odpowiedzi, nasz parser się wywrócił, zadanie leci do kolejki błędów, której nikt nie czyta.
- Wygasły token / certyfikat / hasło — często zauważane po tygodniu, kiedy ktoś przypadkiem zajrzy do logów.
- Blokada po stronie firewalla — nowa polityka IT, nowe adresy IP po migracji, zapomniana whitelista.
- Pełny dysk / full tablespace — zadanie się uruchamia, ale nie ma gdzie zapisać wyniku.
- Rate limiting — zewnętrzne API zaczęło zwracać 429, nasz skrypt próbuje w nieskończoność, kolejka rośnie.
- Logiczna niespójność — dane „przechodzą", ale są bez sensu (klient bez NIP-u, zamówienie z ceną zero, faktura z datą 1970).
Każda z tych awarii ma inny podpis. Dobry monitoring łapie wszystkie, nie tylko „serwer odpowiada".
Trzy warstwy monitoringu
Nie potrzebujecie Datadoga za 2 tys. EUR miesięcznie. Potrzebujecie trzech warstw, każda zbudowana w pół dnia.
Warstwa 1 — czy integracja w ogóle się odpaliła. Każde zadanie integracyjne powinno kończyć się wpisem „zakończono o 03:17, przetworzono 847 rekordów". Jeśli wpisu nie ma, znaczy, że scheduler padł, serwer stanął albo zadanie się zawiesiło. Alert prosty: „jeśli między 3:00 a 3:30 nie było wpisu z sukcesem, wyślij mail". Jedna linijka w cronie, 15 minut roboty.
Warstwa 2 — czy to, co przeszło, ma sens. Tu zaczyna się ciekawie. Alert typu „jeśli dzisiejsza synchronizacja zwróciła 0 rekordów, a wczoraj było 1200, podnieś flagę" wyłapuje większość cichych awarii. Dodajcie też alert w drugą stronę: „jeśli dzisiejsza synchronizacja zwróciła 10× więcej niż średnia z 30 dni, podnieś flagę" — to łapie duplikaty i zapętlenia.
Warstwa 3 — czy dane są biznesowo poprawne. Codzienny raport sprawdzający, że np. każde zamówienie z e-sklepu z ostatnich 24 h ma odpowiadający mu dokument w ERP, a każda faktura w ERP ma pozycję zafiskalizowaną. Prosty skrypt porównujący dwie bazy po ID zamówienia, uruchamiany o 6:00. Jeśli lista rozjazdów jest pusta — milczy. Jeśli ma choć jeden rekord — wysyła maila do dwóch osób.
Trzy warstwy razem łapią jakieś 90% rzeczywistych awarii, które widzimy w praktyce. Reszta to już wyższa szkoła jazdy — i zwykle nie dotyczy firm 10–50-osobowych.
Alerty, które naprawdę ktoś czyta
Największy błąd przy wdrażaniu monitoringu: generowanie alertów, których nikt nie czyta po tygodniu. Potem przychodzi awaria, mail wpada do folderu, w którym leży 400 innych, i nikt go nie widzi.
Kilka zasad, które ratują sytuację:
- Jedna awaria = jeden mail dziennie, nie sto. Jeśli integracja pada 50 razy w nocy, nie wysyłajcie 50 maili. Jeden mail o 7:00 z informacją „50 błędów od 23:00, pierwszy taki, ostatni taki" wystarczy.
- Alert musi mówić, co jest zepsute i co z tym zrobić. „Integracja Allegro — brak odpowiedzi od 2 godzin, prawdopodobnie wygasł token (poprzedni raz: 2026-07-12). Odnów w panelu Allegro: Konto → API." Nie „ERROR: 401 Unauthorized".
- Alerty mają trafić do dwóch osób, nie jednej. Jedna osoba jest na urlopie albo chora. Dwie osoby to minimum ciągłości.
- Osobny kanał dla alertów integracyjnych. Nie wrzucajcie ich do głównej skrzynki admina razem z monitoringiem drukarek. Osobny mail, osobny kanał w Teams, osobny widok.
U wspomnianej hurtowni elektrotechnicznej po wdrożeniu tych reguł średni czas wykrycia awarii integracji spadł z „paru dni" (czyli: do następnej reklamacji) do około 20 minut. Koszt? Trzy dni pracy, zero nowych licencji. Monitoring został zbudowany na SQL Serverze, cronie w Windows i jednej skrzynce w Microsoft 365.
Czego nie da się zmonitorować
Nie wszystko złapie technika. Są rzeczy, które wymagają procesu — czyli człowieka, który raz w tygodniu patrzy na konkretny raport.
Przykłady z życia: zamówienie przychodzi do ERP, ale handlowiec zapomina je przypisać do siebie i nikt nie dzwoni do klienta. System nie widzi tu awarii — dane się przeniosły poprawnie. Albo: integracja z bankiem zaciąga wyciąg, ale 10% płatności nie dopasowuje się automatycznie do faktur (bo klienci wpisują bzdury w tytule przelewu). System to łapie, ale rozwiązać musi ktoś ręcznie.
Dla takich rzeczy nie budujcie monitoringu, tylko krótki, cotygodniowy przegląd. 15 minut w każdy poniedziałek: ktoś (najlepiej ta sama osoba za każdym razem) otwiera raport „niedopasowane płatności", „zamówienia bez przypisanego handlowca", „faktury bez wysyłki". Dopóki raport jest w rotacji — problemy są pod kontrolą. W momencie, w którym ktoś przestaje go otwierać, firma zaczyna cicho tracić pieniądze.
Od czego zacząć w Twojej firmie
Nie od zakupu narzędzia. Od godziny z kartką papieru i listy wszystkich integracji, jakie macie — nawet tych, o których „wszyscy zapomnieli, bo zrobił je 5 lat temu wasz były informatyk".
Dla każdej pozycji z listy odpowiedzcie na trzy pytania: skąd dokąd przepływają dane, co się stanie, jeśli dziś padnie na tydzień, kto się o tym dowie i kiedy. Zwykle wychodzi, że dla połowy integracji odpowiedź na trzecie pytanie brzmi: „klient za 3–5 dni, telefonem".
To jest Wasza lista priorytetów. Zaczynacie od tej, której awaria boli najmocniej.
Jeśli chcecie przegadać, które integracje w Waszej firmie są warto monitorować w pierwszej kolejności — pierwsza rozmowa jest bezpłatna i trwa pół godziny. Wychodzimy z niej z krótką listą „trzech rzeczy do zrobienia w pierwszym miesiącu", nawet jeśli nie skończy się to współpracą.
Integracja, o której nikt nie wie, że padła, nie działa od środy. Wy po prostu dowiecie się o tym w piątek — od klienta.