Powiadomienia e-mail (SMTP) w Uptime Kuma — Gmail, Outlook, własny serwer

Dlaczego powiadomienia e-mail są niezbędne w monitoringu

Monitoring bez powiadomień to jak alarm pożarowy bez syreny — zbiera dane, ale nie ostrzega, kiedy naprawdę trzeba działać. Spośród ponad 90 kanałów powiadomień obsługiwanych przez Uptime Kuma, e-mail pozostaje absolutnym fundamentem strategii alertów. Nie bez powodu — to jedyny kanał, który łączy trzy kluczowe cechy: uniwersalność, niezawodność i trwałość zapisu.

Każdy członek zespołu IT ma skrzynkę e-mail. Nie każdy korzysta z Telegrama, Discorda czy Slacka — ale e-mail jest wszędzie. Według badań Radicati Group na świecie istnieje ponad 4,6 miliarda aktywnych kont e-mail, co czyni ten kanał najbardziej uniwersalnym medium komunikacji cyfrowej. W kontekście monitoringu infrastruktury oznacza to, że powiadomienie e-mail dotrze do każdego odbiorcy — niezależnie od platformy, systemu operacyjnego czy preferencji komunikacyjnych.

E-mail ma też unikalną zaletę, której nie oferują komunikatory: trwały, przeszukiwalny zapis. Każdy alert trafia do skrzynki, gdzie można go oznaczyć, przypisać do folderu, wyszukać po dacie lub temacie. Trzy miesiące później, gdy audytor pyta „kiedy ostatnio padał serwer produkcyjny?", odpowiedź jest w Twoim Outlooku — z dokładnym timestampem, szczegółami awarii i informacją o przywróceniu usługi.

Co więcej, e-mail działa niezawodnie nawet wtedy, gdy inne kanały zawodzą. Telegram może mieć problemy z dostarczaniem w niektórych regionach, webhook Slacka może przestać działać po zmianie tokena, a SMS-y są kosztowne i ograniczone. Tymczasem protokół SMTP — rdzenny protokół poczty elektronicznej — jest jednym z najstarszych i najstabilniejszych elementów infrastruktury internetowej, działającym od 1982 roku.

Jak działa SMTP w Uptime Kuma — przegląd konfiguracji

SMTP (Simple Mail Transfer Protocol) to standardowy protokół internetowy służący do wysyłania wiadomości e-mail. Gdy Uptime Kuma wykryje awarię monitorowanej usługi, łączy się z serwerem SMTP (np. Gmail, Outlook lub Twoim własnym) i za jego pośrednictwem wysyła wiadomość e-mail do zdefiniowanych odbiorców. To dokładnie ten sam mechanizm, z którego korzysta Twój program pocztowy — Thunderbird, Outlook czy Apple Mail — gdy klikasz „Wyślij".

Konfiguracja powiadomień e-mail w Uptime Kuma wymaga podania kilku podstawowych informacji:

Gdzie znaleźć ustawienia powiadomień

Aby skonfigurować powiadomienia e-mail w Uptime Kuma, wykonaj następujące kroki:

Gmail SMTP — konfiguracja krok po kroku

Gmail jest jednym z najpopularniejszych dostawców poczty e-mail na świecie, dlatego wielu administratorów chce wykorzystać go jako serwer SMTP dla powiadomień z Uptime Kuma. Konfiguracja jest prosta, ale wymaga kilku dodatkowych kroków bezpieczeństwa — Google domyślnie blokuje logowanie do konta przez zewnętrzne aplikacje za pomocą zwykłego hasła.

Krok 1: Włącz weryfikację dwuetapową

Aby korzystać z App Passwords (haseł aplikacji), Twoje konto Google musi mieć włączoną weryfikację dwuetapową (2-Step Verification). Przejdź do myaccount.google.com/security i włącz tę opcję, jeśli jeszcze tego nie zrobiłeś.

Krok 2: Wygeneruj App Password

App Password to jednorazowe, 16-znakowe hasło, które pozwala zewnętrznej aplikacji (w tym przypadku Uptime Kuma) logować się do Twojego konta Gmail bez użycia głównego hasła. Aby je wygenerować:

Krok 3: Skonfiguruj SMTP w Uptime Kuma

Wprowadź następujące dane w formularzu powiadomień Uptime Kuma:

Alternatywna konfiguracja: port 587 z STARTTLS

Gmail obsługuje również port 587 z szyfrowaniem STARTTLS. Jeśli port 465 jest zablokowany przez firewall lub dostawcę hostingu, użyj tej konfiguracji:

Pozostałe parametry (hostname, username, password) pozostają bez zmian.

Limity wysyłania Gmail

Gmail nakłada limity na liczbę wiadomości wysyłanych przez SMTP. Dla zwykłego konta Gmail limit wynosi 500 wiadomości na dobę, a dla Google Workspace (dawniej G Suite) — 2 000 wiadomości na dobę. W kontekście monitoringu to zwykle wystarczający limit, ale jeśli monitorujesz setki usług z agresywnymi interwałami — warto rozważyć dedykowany serwer SMTP.

A co z Google Workspace i OAuth2?

Jeśli korzystasz z Google Workspace (konto firmowe), konfiguracja SMTP jest identyczna — zmienia się jedynie adres e-mail (np. monitoring@twojafirma.pl zamiast @gmail.com). App Password generujesz tak samo.

Uptime Kuma obsługuje uwierzytelnianie SMTP wyłącznie przez LOGIN/PLAIN (username + password). Nie obsługuje bezpośrednio OAuth2 dla SMTP. W praktyce App Password jest wystarczające i bezpieczne — to standardowa metoda rekomendowana przez Google dla aplikacji zewnętrznych.

Outlook i Microsoft 365 — konfiguracja SMTP

Microsoft Outlook (zarówno darmowy Outlook.com, jak i Microsoft 365 / Exchange Online) to drugi najpopularniejszy dostawca poczty e-mail w środowiskach firmowych. Konfiguracja SMTP w Uptime Kuma jest prosta, choć wymaga kilku uwag dotyczących bezpieczeństwa i polityk organizacyjnych.

Konfiguracja dla Outlook.com (darmowe konto)

Konfiguracja dla Microsoft 365 (Exchange Online)

W środowiskach Microsoft 365 konfiguracja SMTP może być nieco bardziej skomplikowana ze względu na polityki bezpieczeństwa organizacji. Dane połączenia:

Włączanie SMTP AUTH w Microsoft 365

Aby włączyć SMTP AUTH dla konkretnego konta w Microsoft 365:

Alternatywnie, administrator może włączyć SMTP AUTH przez PowerShell:

Set-CASMailbox -Identity "monitoring@twojafirma.pl" -SmtpClientAuthenticationDisabled $false

App Password w Outlook z 2FA

Jeśli konto Outlook/M365 ma włączoną weryfikację wieloskładnikową (MFA/2FA), musisz wygenerować App Password — tak samo jak w przypadku Gmaila. Przejdź do account.live.com/proofs/AppPassword (dla Outlook.com) lub mysignins.microsoft.com/security-info (dla M365) i utwórz hasło aplikacji.

Limity wysyłania Outlook/M365

Microsoft stosuje następujące limity dla SMTP:

• Outlook.com (darmowy): 300 wiadomości dziennie
• Microsoft 365 Business: 10 000 wiadomości dziennie (max 30 wiadomości/minutę)
• Exchange Online: 10 000 odbiorców dziennie

Dla typowego monitoringu te limity są więcej niż wystarczające. Przy 100 monitorach i standardowych interwałach nie powinieneś nawet zbliżyć się do tych limitów.

Własny serwer SMTP — pełna kontrola nad powiadomieniami

Jeśli zależy Ci na pełnej kontroli nad wysyłką e-maili, braku ograniczeń narzucanych przez zewnętrznych dostawców i zgodności z politykami korporacyjnymi — własny serwer SMTP to najlepsza opcja. Może to być serwer pocztowy na Twoim hostingu, dedykowana usługa transakcyjna (Mailgun, SendGrid, Amazon SES) lub klasyczny serwer SMTP w firmowej infrastrukturze.

Konfiguracja z serwerem hostingowym

Większość dostawców hostingu udostępnia serwer SMTP jako część usługi. Dane połączenia znajdziesz w panelu administracyjnym hostingu (cPanel, DirectAdmin, Plesk). Typowa konfiguracja:

Konfiguracja z usługami transakcyjnymi

Usługi takie jak Mailgun, SendGrid, Amazon SES czy Postmark są stworzone specjalnie do wysyłania e-maili automatycznych i transakcyjnych. Oferują wysoką dostarczalność, szczegółowe statystyki i gotowe rekordy SPF/DKIM. Oto przykładowe konfiguracje:

Mailgun

SendGrid

Amazon SES

Własny serwer pocztowy (Postfix, Exim, hMailServer)

Jeśli zarządzasz własnym serwerem pocztowym — np. Postfix na Linuxie, Exim na cPanelu czy hMailServer na Windows — konfiguracja SMTP jest analogiczna. Podajesz adres serwera (IP lub hostname), port, typ szyfrowania i dane logowania.

Przykład konfiguracji dla Postfixa działającego na tym samym serwerze co Uptime Kuma:

Porty, TLS i SSL — co wybrać i dlaczego

Jeden z najczęstszych powodów problemów z konfiguracją SMTP to niepoprawny dobór portu i typu szyfrowania. Oto szczegółowe zestawienie wszystkich opcji:

Która opcja jest lepsza: SSL/TLS (465) czy STARTTLS (587)?

Obie opcje zapewniają szyfrowanie połączenia — różnią się sposobem nawiązania sesji TLS:

• Port 465 (implicit TLS) — szyfrowanie od pierwszego bajtu. Nie ma okna, w którym dane mogłyby lecieć otwartym tekstem. To jak wejście do budynku, który z zewnątrz jest już zamknięty na klucz.
• Port 587 (STARTTLS) — połączenie zaczyna się w trybie jawnym, a klient „prosi" serwer o przejście na TLS. Teoretycznie podatne na atak MITM (man-in-the-middle) w momencie „przeskoku", choć w praktyce ryzyko jest minimalne.

W kontekście Uptime Kuma obie opcje działają poprawnie. Wybieraj port zgodnie z tym, co obsługuje Twój dostawca SMTP — Gmail preferuje 465, Outlook wymaga 587.

Ustawienie Ignore TLS Error

W formularzu konfiguracji SMTP w Uptime Kuma znajdziesz opcję Ignore TLS Error. Gdy jest włączona, Uptime Kuma nie będzie weryfikować certyfikatu SSL serwera SMTP. To przydatne w kilku scenariuszach:

• Serwer SMTP używa certyfikatu self-signed (samopodpisanego)
• Hostname SMTP nie pasuje do certyfikatu (np. łączysz się z IP zamiast z nazwy)
• Certyfikat wygasł (tymczasowe obejście — naprawa certyfikatu jest lepszym rozwiązaniem)

W środowisku produkcyjnym zalecamy pozostawienie tej opcji wyłączonej — poprawny certyfikat TLS jest standardem i chroni przed atakami MITM.

Personalizacja treści e-mail — szablony i zmienne

Uptime Kuma pozwala na personalizację treści powiadomień e-mail, dzięki czemu alerty mogą zawierać dokładnie te informacje, które potrzebujesz do szybkiej diagnostyki. Domyślne wiadomości są czytelne i zawierają najważniejsze dane, ale możesz je dostosować za pomocą Custom Subject (niestandardowy temat wiadomości).

Domyślna treść powiadomienia

Standardowy e-mail z Uptime Kuma zawiera:

• Temat: np. „[Uptime Kuma] Website - DOWN" lub „[Uptime Kuma] API Server - UP"
• Treść: nazwa monitora, status (UP/DOWN), czas odpowiedzi, timestamp, opis błędu (jeśli dotyczy)

Zmienne dostępne w szablonach

W polu Custom Email Subject możesz używać zmiennych LiquidJS (silnik szablonów oparty na Shopify Liquid), które Uptime Kuma automatycznie zastąpi aktualnymi wartościami. Najważniejsze zmienne:

Przykłady niestandardowych tematów

Oto kilka praktycznych przykładów Custom Subject, które ułatwią filtrowanie i sortowanie alertów w skrzynce e-mail:

⚠ ALERT: {{monitorJSON.name}} is {{heartbeatJSON.status == 1 ? "UP" : "DOWN"}}

[Monitoring] {{monitorJSON.name}} — {{heartbeatJSON.msg}}

[{{monitorJSON.name}}] Status: {{heartbeatJSON.status == 1 ? "OK" : "AWARIA"}} | Ping: {{heartbeatJSON.ping}}ms

Wiele odbiorców

W polu To Email możesz podać wiele adresów e-mail rozdzielonych przecinkami. Dzięki temu jeden alert trafia jednocześnie do kilku osób:

admin@firma.pl, devops@firma.pl, oncall@firma.pl

Alternatywnie możesz utworzyć wiele konfiguracji powiadomień e-mail — osobno dla zespołu DevOps, osobno dla managementu, osobno dla klienta — i przypisywać je do różnych monitorów. To daje pełną elastyczność w kierowaniu alertów do odpowiednich odbiorców.

Testowanie powiadomień i rozwiązywanie problemów

Konfiguracja SMTP to jedna z tych rzeczy, które albo działają od razu, albo sprawiają problemy wymagające systematycznej diagnostyki. Uptime Kuma udostępnia przycisk Test, który wysyła próbną wiadomość — to zawsze pierwszy krok. Jeśli test nie zadziała, poniżej znajdziesz najczęstsze problemy i sposoby ich rozwiązania.

Najczęstsze błędy i rozwiązania

Diagnostyka krok po kroku

Jeśli przycisk Test w Uptime Kuma zwraca błąd, wykonaj następujące kroki diagnostyczne:

# Test połączenia na port 587
nc -zv smtp.gmail.com 587

# Test połączenia na port 465
nc -zv smtp.gmail.com 465

# Lub za pomocą openssl (z weryfikacją certyfikatu)
openssl s_client -connect smtp.gmail.com:465

E-mail w połączeniu z innymi kanałami powiadomień

E-mail jest niezastąpionym kanałem powiadomień, ale najlepszą praktyką jest łączenie go z innymi kanałami — tak, aby żaden alert nie przeszedł niezauważony. Uptime Kuma pozwala przypisać do jednego monitora wiele kanałów powiadomień jednocześnie, co daje wielowarstwową strategię alertów.

Rekomendowane kombinacje

Jak przypisać wiele powiadomień do monitora

W Uptime Kuma możesz przypisać dowolną liczbę kanałów powiadomień do jednego monitora. Podczas tworzenia lub edycji monitora, w sekcji Notifications, zaznacz checkboxy przy wybranych kanałach. Każdy zaznaczony kanał otrzyma alert niezależnie od pozostałych.

Możesz też ustawić domyślne powiadomienia — kanały, które będą automatycznie przypisywane do każdego nowego monitora. To idealne rozwiązanie dla e-maila — zazwyczaj chcesz, aby każdy monitor wysyłał alert mailowy, a dodatkowe kanały (Telegram, Slack) przypisujesz selektywnie.

Resend Notification — ponawianie alertów

Uptime Kuma oferuje funkcję Resend Notification, która ponawia wysyłkę powiadomienia w określonych interwałach, dopóki usługa nie wróci do stanu UP. To ważne w przypadku e-maili — jeden alert może umknąć w lawinie codziennych wiadomości, ale powtarzane co 5 lub 15 minut przypomnienie trudno przeoczyć.

Ustawienie Resend Notification znajdziesz w konfiguracji monitora (nie powiadomienia) — w sekcji Notification → Resend Notification every X times. Ustawienie wartości 5 oznacza, że powiadomienie zostanie wysłane ponownie co 5 heartbeatów (np. co 5 minut przy interwale 60-sekundowym).

Najlepsze praktyki — SPF, DKIM, limity i dedykowane adresy

Prawidłowa konfiguracja SMTP to dopiero początek. Aby powiadomienia e-mail z Uptime Kuma były niezawodne, trafiały do skrzynki odbiorczej (a nie do spamu) i nie stwarzały ryzyka bezpieczeństwa, warto zastosować poniższe praktyki.

1. Użyj dedykowanego adresu nadawcy

Nie wysyłaj alertów ze swojego osobistego adresu e-mail. Utwórz dedykowane konto — np. monitoring@twojadomena.pl, uptime@twojadomena.pl lub alerts@twojadomena.pl. Korzyści:

• Łatwe filtrowanie i reguły w skrzynce odbiorczej
• Oddzielenie ruchu monitoringowego od korespondencji osobistej
• Brak ryzyka zablokowania głównego konta za „masową wysyłkę"
• Możliwość współdzielenia dostępu do konta monitoringowego w zespole

2. Skonfiguruj rekordy SPF i DKIM

Jeśli wysyłasz alerty z własnej domeny (nie z Gmail czy Outlook), koniecznie skonfiguruj rekordy SPF i DKIM w DNS. Bez nich Twoje e-maile z dużym prawdopodobieństwem trafią do spamu lub zostaną odrzucone przez serwery odbiorców.

SPF (Sender Policy Framework) informuje serwery odbiorcze, które serwery SMTP są uprawnione do wysyłania e-maili z Twojej domeny. Przykładowy rekord DNS TXT:

twojadomena.pl.  IN  TXT  "v=spf1 a mx include:_spf.google.com ~all"

DKIM (DomainKeys Identified Mail) dodaje podpis kryptograficzny do nagłówków wiadomości, potwierdzając, że e-mail naprawdę pochodzi z Twojej domeny i nie został zmodyfikowany w drodze. Konfiguracja DKIM wymaga wygenerowania pary kluczy i dodania klucza publicznego jako rekordu DNS TXT.

DMARC to nadrzędna polityka, która łączy SPF i DKIM, definiując co robić z wiadomościami, które nie przechodzą weryfikacji. Minimalny rekord DMARC:

_dmarc.twojadomena.pl.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@twojadomena.pl"

3. Pamiętaj o limitach wysyłania

Każdy dostawca SMTP narzuca limity. Podsumowanie najważniejszych:

W typowym scenariuszu monitoringu — 50 monitorów, alert średnio raz dziennie — zużywasz 50-100 e-maili dziennie. To mieści się w limitach nawet darmowego Gmaila. Problem może pojawić się przy masowych awariach (np. awaria sieci wpływająca na 100+ usług jednocześnie) lub przy włączonym Resend Notification z agresywnym interwałem.

4. Ustaw Resend Notification z rozsądkiem

Funkcja Resend Notification jest cenna, ale zbyt agresywne ustawienia mogą zalać skrzynkę e-mail setkami powiadomień. Rekomendacja:

• Usługi krytyczne: resend co 5-10 heartbeatów (np. co 5-10 minut)
• Usługi standardowe: resend co 30-60 heartbeatów (np. co 30-60 minut)
• Usługi informacyjne: bez resend — wystarczy jeden alert

5. Testuj powiadomienia regularnie

Konfiguracja SMTP, która działała w styczniu, może przestać działać w marcu — bo wygasło App Password, zmienił się serwer SMTP dostawcy, albo administrator IT zmienił politykę bezpieczeństwa M365. Rekomendacja: testuj powiadomienia e-mail co najmniej raz w miesiącu za pomocą przycisku Test w Uptime Kuma.

6. Monitoruj sam monitoring

Brzmi jak paradoks, ale to kluczowa praktyka: upewnij się, że Twoja instancja Uptime Kuma jest sama monitorowana przez zewnętrzny serwis. Jeśli serwer z Uptime Kuma padnie, nie dostaniesz alertu o awarii monitorowanych usług — bo system alertów też nie działa. Rozwiązanie: druga instancja Uptime Kuma w innej lokalizacji, zewnętrzny uptime monitor lub prosty cron z curl + e-mail.

Podsumowanie

Powiadomienia e-mail przez SMTP to fundament skutecznego monitoringu w Uptime Kuma. Niezależnie od tego, czy korzystasz z Gmaila, Outlooka, Microsoft 365 czy własnego serwera pocztowego — konfiguracja jest prosta i zajmuje kilka minut. Kluczowe punkty do zapamiętania:

• Gmail: port 465 (SSL) lub 587 (STARTTLS), wymaga App Password — nie zwykłego hasła
• Outlook/M365: port 587 (STARTTLS), wymaga włączenia SMTP AUTH w Exchange Admin Center
• Własny serwer: pełna elastyczność — skonfiguruj SPF, DKIM i DMARC dla optymalnej dostarczalności
• Szyfrowanie: zawsze używaj TLS (port 465 lub 587) — nigdy nie wysyłaj alertów nieszyfrowanym kanałem
• Personalizacja: wykorzystaj zmienne LiquidJS w Custom Subject, aby alerty były czytelne i łatwe do filtrowania
• Redundancja: łącz e-mail z innymi kanałami (Telegram, Slack, PagerDuty) dla wielowarstwowej strategii alertów
• Testowanie: regularnie testuj powiadomienia przyciskiem Test — konfiguracja SMTP może się zmienić bez ostrzeżenia

E-mail nie jest jedynym kanałem powiadomień w Uptime Kuma — ale jest tym, od którego warto zacząć. Jest uniwersalny, niezawodny i tworzy trwały zapis każdej awarii. Dobrze skonfigurowane powiadomienia e-mail to różnica między „dowiedzieliśmy się o awarii po 2 godzinach od klientów" a „zareagowaliśmy w 2 minuty, zanim ktokolwiek zauważył problem".