Dlaczego powiadomienia e-mail są niezbędne w monitoringu • Jak działa SMTP w Uptime Kuma — przegląd konfiguracji • Gmail SMTP — konfiguracja krok po kroku • Outlook i Microsoft 365 — konfiguracja SMTP • Własny serwer SMTP — pełna kontrola nad powiadomieniami • Porty, TLS i SSL — co wybrać i dlaczego • Personalizacja treści e-mail — szablony i zmienne • Testowanie powiadomień i rozwiązywanie problemów • E-mail w połączeniu z innymi kanałami powiadomień • Najlepsze praktyki — SPF, DKIM, limity i dedykowane adresy • Podsumowanie • Najczęściej zadawane pytania
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.
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:
| Parametr | Opis | Przykład |
|---|---|---|
| SMTP Host | Adres serwera SMTP | smtp.gmail.com |
| SMTP Port | Port połączenia | 465 lub 587 |
| Security | Typ szyfrowania | TLS (STARTTLS) lub SSL |
| Username | Login do konta SMTP | monitoring@twojafirma.pl |
| Password | Hasło lub App Password | abcd efgh ijkl mnop |
| From Email | Adres nadawcy | monitoring@twojafirma.pl |
| To Email | Adres(y) odbiorcy | admin@twojafirma.pl |
Aby skonfigurować powiadomienia e-mail w Uptime Kuma, wykonaj następujące kroki:
1.
Zaloguj się do Uptime Kuma, kliknij ikonę dzwonka w prawym górnym rogu lub przejdź do Settings → Notifications. Następnie kliknij przycisk Setup Notification.
2.
Z listy rozwijanej Notification Type wybierz Email (SMTP). Uptime Kuma wyświetli formularz z polami konfiguracji serwera SMTP.
3.
Wprowadź dane serwera SMTP — hostname, port, typ szyfrowania, login i hasło. Szczegóły konfiguracji dla poszczególnych dostawców (Gmail, Outlook, własny serwer) znajdziesz w dalszych sekcjach tego artykułu.
4.
Kliknij przycisk Test na dole formularza. Jeśli konfiguracja jest poprawna, otrzymasz testowy e-mail w ciągu kilku sekund. Jeśli nie — sprawdź sekcję Troubleshooting w dalszej części artykułu.
1.
Otwórz myaccount.google.com/apppasswords (lub wyszukaj „App passwords" w ustawieniach konta Google).
2.
W polu nazwy wpisz np. „Uptime Kuma" — to pomoże Ci później zidentyfikować, do czego służy to hasło. Kliknij Create.
3.
Google wyświetli 16-znakowy kod w formacie abcd efgh ijkl mnop. Skopiuj go — to będzie Twoje hasło SMTP. Uwaga: hasło wyświetla się tylko raz, więc skopiuj je od razu.
1.
Zaloguj się do admin.exchange.microsoft.com jako administrator.
2.
Przejdź do Recipients → Mailboxes, znajdź konto, którego chcesz użyć do wysyłania alertów.
3.
Kliknij na konto, przejdź do zakładki Email apps (lub Manage email apps), zaznacz opcję Authenticated SMTP i zapisz zmiany. Zmiana może wymagać kilku minut na propagację.
1.
Upewnij się, że username to pełny adres e-mail, a hasło to App Password (nie zwykłe hasło konta). Sprawdź, czy nie ma dodatkowych spacji przed lub po haśle.
2.
Port 465 = SSL/TLS, port 587 = STARTTLS. Wybranie złego typu szyfrowania dla danego portu to jedna z najczęstszych przyczyn problemów. Upewnij się, że kombinacja port + security zgadza się z wymaganiami dostawcy.
3.
Jeśli masz dostęp SSH do serwera z Uptime Kuma, przetestuj połączenie z serwerem SMTP:
# 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:4654.
W logach aplikacji (dostępnych przez docker logs uptime-kuma lub w konsoli terminala) znajdziesz szczegółowe informacje o błędach SMTP — w tym kody odpowiedzi serwera, które precyzyjnie wskazują przyczynę problemu.
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.
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ś.
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ć:
Wprowadź następujące dane w formularzu powiadomień Uptime Kuma:
| Parametr | Wartość |
|---|---|
| Hostname | smtp.gmail.com |
| Port | 465 |
| Security | SSL / TLS |
| Username | Twój adres Gmail, np. monitoring@gmail.com |
| Password | App Password (16-znakowy kod z poprzedniego kroku) |
| From Email | Twój adres Gmail |
| To Email | Adres(y) odbiorcy alertów |
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:
| Parametr | Wartość |
|---|---|
| Port | 587 |
| Security | STARTTLS |
Pozostałe parametry (hostname, username, password) pozostają bez zmian.
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.
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.
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.
| Parametr | Wartość |
|---|---|
| Hostname | smtp-mail.outlook.com |
| Port | 587 |
| Security | STARTTLS |
| Username | Twój adres Outlook, np. monitoring@outlook.com |
| Password | Hasło do konta (lub App Password, jeśli masz włączone 2FA) |
| From Email | Twój adres Outlook |
| To Email | Adres(y) odbiorcy |
W środowiskach Microsoft 365 konfiguracja SMTP może być nieco bardziej skomplikowana ze względu na polityki bezpieczeństwa organizacji. Dane połączenia:
| Parametr | Wartość |
|---|---|
| Hostname | smtp.office365.com |
| Port | 587 |
| Security | STARTTLS |
| Username | Adres e-mail konta M365 |
| Password | Hasło konta lub App Password |
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 $falseJeś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.
Microsoft stosuje następujące limity dla SMTP:
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.
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.
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:
| Parametr | Przykładowa wartość |
|---|---|
| Hostname | mail.twojadomena.pl lub smtp.twojadomena.pl |
| Port | 465 (SSL) lub 587 (STARTTLS) |
| Security | SSL/TLS lub STARTTLS |
| Username | Pełny adres e-mail, np. monitoring@twojadomena.pl |
| Password | Hasło do konta e-mail |
monitoring@twojadomena.pl lub uptime-kuma@twojadomena.pl. Oddzielenie ruchu monitoringowego od normalnej korespondencji firmowej ułatwia filtrowanie, diagnostykę i zapobiega przypadkowemu osiągnięciu limitów.
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:
| Parametr | Wartość |
|---|---|
| Hostname | smtp.mailgun.org |
| Port | 587 |
| Security | STARTTLS |
| Username | Login z panelu Mailgun (zwykle postmaster@twojadomena.pl) |
| Password | Hasło SMTP z panelu Mailgun |
| Parametr | Wartość |
|---|---|
| Hostname | smtp.sendgrid.net |
| Port | 587 |
| Security | STARTTLS |
| Username | apikey (stały — zawsze „apikey") |
| Password | Twój API Key z panelu SendGrid |
| Parametr | Wartość |
|---|---|
| Hostname | email-smtp.eu-central-1.amazonaws.com (region Frankfurt) |
| Port | 587 |
| Security | STARTTLS |
| Username | SMTP Credentials z AWS IAM |
| Password | SMTP Password z AWS IAM |
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:
| Parametr | Wartość |
|---|---|
| Hostname | localhost lub 127.0.0.1 |
| Port | 25 (bez TLS) lub 587 (z STARTTLS) |
| Security | None (localhost) lub STARTTLS |
| Username | Login do konta SMTP (lub puste, jeśli serwer nie wymaga autoryzacji dla localhost) |
| Password | Hasło (lub puste) |
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:
| Port | Szyfrowanie | Opis | Rekomendacja |
|---|---|---|---|
| 25 | Brak (lub opcjonalny STARTTLS) | Tradycyjny port SMTP do komunikacji serwer-serwer (MTA relay). Często blokowany przez ISP i dostawców chmury. | Nie zalecany dla klientów SMTP. Używaj tylko do komunikacji localhost → lokalny Postfix. |
| 465 | SSL/TLS (implicit) | Połączenie jest szyfrowane od samego początku (implicit TLS). Klient od razu nawiązuje połączenie TLS. Oficjalnie przywrócony w RFC 8314 (2018). | Rekomendowany — najlepsze bezpieczeństwo. Używany przez Gmail (smtp.gmail.com:465). |
| 587 | STARTTLS (explicit) | Połączenie zaczyna się jako nieszyfrowane, a następnie jest „podnoszone" do TLS za pomocą komendy STARTTLS. Standardowy port submission (RFC 6409). | Rekomendowany — najszerzej wspierany. Używany przez Outlook, Mailgun, SendGrid. |
| 2525 | STARTTLS | Alternatywny port SMTP, używany gdy 587 jest blokowany. Nieoficjalny, ale szeroko wspierany przez usługi transakcyjne. | Używaj jako fallback, gdy 587 nie działa. |
Obie opcje zapewniają szyfrowanie połączenia — różnią się sposobem nawiązania sesji TLS:
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.
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:
W środowisku produkcyjnym zalecamy pozostawienie tej opcji wyłączonej — poprawny certyfikat TLS jest standardem i chroni przed atakami MITM.
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).
Standardowy e-mail z Uptime Kuma zawiera:
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:
| Zmienna | Opis | Przykład wartości |
|---|---|---|
{{monitorJSON.name}} | Nazwa monitora | Strona firmowa |
{{monitorJSON.url}} | URL monitorowanej usługi | https://twojafirma.pl |
{{monitorJSON.hostname}} | Hostname monitora | twojafirma.pl |
{{monitorJSON.port}} | Port monitora | 443 |
{{heartbeatJSON.status}} | Status (0 = DOWN, 1 = UP, 2 = PENDING) | 0 |
{{heartbeatJSON.msg}} | Wiadomość diagnostyczna | Connection timed out |
{{heartbeatJSON.ping}} | Czas odpowiedzi (ms) | 245 |
{{heartbeatJSON.time}} | Timestamp zdarzenia | 2026-03-24 14:30:00 |
{{msg}} | Pełna wiadomość powiadomienia | [Strona firmowa] [DOWN]... |
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}}msW 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.plAlternatywnie 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.
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.
| Błąd / Objaw | Prawdopodobna przyczyna | Rozwiązanie |
|---|---|---|
Connection refused | Zły port, firewall blokuje połączenie, serwer SMTP nie działa | Sprawdź port (465/587), upewnij się, że firewall pozwala na połączenia wychodzące na wybrany port. Przetestuj telnetem: telnet smtp.gmail.com 587 |
Authentication failed | Niepoprawny login/hasło, użyte zwykłe hasło zamiast App Password | Wygeneruj nowe App Password (Gmail) lub włącz SMTP AUTH (M365). Sprawdź dokładnie login — musi to być pełny adres e-mail. |
Connection timed out | Firewall, ISP blokuje port 25/465/587, serwer SMTP nieosiągalny | Zmień port (np. z 465 na 587 lub odwrotnie). Sprawdź u dostawcy hostingu/VPS, czy porty SMTP nie są blokowane. |
TLS/SSL error lub self-signed certificate | Certyfikat serwera SMTP jest samopodpisany, wygasł lub hostname nie pasuje | Włącz opcję „Ignore TLS Error" (tymczasowe obejście) lub napraw certyfikat serwera SMTP. |
Greeting never received | Port wymaga innego typu szyfrowania niż wybrany | Port 465 wymaga SSL/TLS, port 587 wymaga STARTTLS. Upewnij się, że wybrałeś właściwy typ Security. |
| E-mail trafia do spamu | Brak rekordów SPF/DKIM, zła reputacja domeny nadawcy | Skonfiguruj rekordy SPF i DKIM w DNS domeny nadawcy — szczegóły w sekcji Best practices. |
| E-mail nie dociera wcale | Adres „From" nie pasuje do konta SMTP, domena zablokowana przez dostawcę | Upewnij się, że adres From Email jest taki sam jak Username (lub aliasem w domenie konta SMTP). |
Jeśli przycisk Test w Uptime Kuma zwraca błąd, wykonaj następujące kroki diagnostyczne:
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.
| Scenariusz | Kanały powiadomień | Dlaczego |
|---|---|---|
| Mały zespół / freelancer | E-mail + Telegram | E-mail jako trwały zapis, Telegram jako natychmiastowy alert z dźwiękiem push na telefonie |
| Zespół DevOps | E-mail + Slack/Discord + PagerDuty | E-mail do archiwum, Slack/Discord do komunikacji w zespole, PagerDuty do eskalacji i on-call rotation |
| Agencja webowa | E-mail (klient) + Telegram (zespół) + webhook (ITSM) | Klient dostaje raport e-mail, zespół reaguje przez Telegram, system ticketowy tworzy ticket automatycznie |
| Infrastruktura krytyczna | E-mail + SMS + PagerDuty + Ntfy | Wielopoziomowa redundancja — jeśli jeden kanał zawiedzie, pozostałe dostarczą alert |
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.
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).
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.
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:
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"Każdy dostawca SMTP narzuca limity. Podsumowanie najważniejszych:
| Dostawca | Limit dzienny | Limit minutowy | Uwagi |
|---|---|---|---|
| Gmail (darmowy) | 500 | ~20 | App Password wymagane |
| Google Workspace | 2 000 | ~30 | Per użytkownik |
| Outlook.com | 300 | ~30 | Ograniczenia antispam |
| Microsoft 365 | 10 000 | 30 | SMTP AUTH wymagane |
| Mailgun (darmowy) | 100 | - | Po weryfikacji domeny: 5 000/mies. |
| SendGrid (darmowy) | 100 | - | Płatne plany: 100+/dzień |
| Amazon SES | 50 000+ | 14/sek | Zależy od planu; wymaga weryfikacji |
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.
Funkcja Resend Notification jest cenna, ale zbyt agresywne ustawienia mogą zalać skrzynkę e-mail setkami powiadomień. Rekomendacja:
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.
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.
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:
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".
smtp.gmail.com, port 465 (SSL) lub 587 (STARTTLS). Limit darmowego Gmaila to 500 wiadomości dziennie, co jest wystarczające dla typowego monitoringu.admin@firma.pl, devops@firma.pl). Po drugie, możesz utworzyć wiele osobnych konfiguracji powiadomień e-mail z różnymi odbiorcami i przypisywać je selektywnie do różnych monitorów — np. alerty o stronie firmowej trafiają do marketingu, a o API do zespołu DevOps.user@gmail.com, nie samo user); (3) czy nie ma dodatkowych spacji w polu hasła (skopiuj i wklej ponownie). Dla Microsoft 365 upewnij się dodatkowo, że SMTP AUTH jest włączony dla danego konta w Exchange Admin Center.