Problem, który rozwiązują alerty
Większość awarii wychodzi na jaw dopiero wtedy, gdy użytkownicy zaczynają pisać na kanale ogólnym albo w ticketach. Do tego momentu strona może leżeć, API płatności zwracać błędy, a serwer gry nie odpowiadać — a Ty dowiadujesz się o tym od społeczności, nie od systemu. Alerty na Discordzie lub Telegramie skracają czas reakcji z godzin do minut, bo powiadomienie trafia tam, gdzie i tak jesteś online.
Jak to zwykle działa
Architektura jest prosta i powtarzalna niezależnie od tego, czy monitorujesz stronę WWW, endpoint REST czy port serwera gry. Co jakiś czas (np. co 30-60 sekund) skrypt albo zewnętrzny serwis sprawdza, czy usługa odpowiada poprawnie. Przy zmianie statusu z OK na down wysyłana jest wiadomość alertowa; przy powrocie do normy — osobne powiadomienie „serwis wrócił”. Kanał alertów powinien być osobny, widoczny tylko dla adminów, żeby nie zaśmiecać kanałów publicznych.
- Health check co X sekund (HTTP, ping, TCP port).
- Detekcja zmiany stanu (OK → down, down → OK).
- Wysyłka wiadomości na Discord (webhook lub bot) albo Telegram (Bot API).
- Opcjonalnie: eskalacja (np. ping roli on-call) po przekroczeniu progu czasu.
Discord vs Telegram
Na Discordzie najszybciej startujesz z webhookiem — nie potrzebujesz pełnej aplikacji bota, wystarczy URL i payload JSON. Jeśli alerty mają być częścią większego bota (np. razem z komendami admina), lepiej użyć tokena bota i wysyłać wiadomości przez Discord API. Na Telegramie analogicznie: bot wysyła wiadomość na czat lub do grupy przez Telegram Bot API. Oba kanały można spiąć równolegle — wtedy awaria trafia do dwóch miejsc naraz.
Co warto monitorować
- Strona WWW, landing i panel klienta (HTTP 200 + czas odpowiedzi).
- API płatności, backend bota i baza danych (endpoint /health).
- Serwer gry, VPS albo usługę krytyczną dla społeczności (port, proces).
- Webhooki zewnętrzne — czy callbacki w ogóle dochodzą.
Czego unikać
Najczęstszy błąd to flood: alert co minutę „serwer down”, bez deduplikacji i bez informacji, kiedy problem się zaczął. Lepiej wysłać jeden alert przy padnięciu, jeden przy powrocie i ewentualnie przypomnienie co 15-30 minut, jeśli usługa nadal leży. Drugi problem to brak kontekstu — sama informacja „down” nie wystarczy. Dodaj nazwę usługi, timestamp, ostatni kod HTTP i link do dashboardu. Trzeci błąd to brak testów: wyłącz usługę celowo i sprawdź, czy alert faktycznie dochodzi, zanim polegniesz na tym w produkcji.
Hosting monitora
Monitor powinien działać poza infrastrukturą, którą obserwujesz — inaczej padnie razem z nią i nie wyśle alertu. Zewnętrzny uptime checker, cron na osobnym VPS albo serverless function to sensowne opcje. Przy własnym skrypcie pamiętaj o stabilnym hostingu i logowaniu błędów samego monitora. Powiązane tematy: bezpieczeństwo bota (token webhooka też trzymaj w sekrecie).
Chcesz gotowy system alertów spięty z botem Discord/Telegram — napisz przez formularz kontaktowy.