Pierwszy retainer typowo zaczyna się od "wszystkie alerty na #automation-alerts". Po 2 tygodniach kanał ma 200 wiadomości dziennie, nikt nie czyta, krytyczny incident leci 4 godziny zanim ktoś zauważy. Ten przewodnik tłumaczy jak nie wpaść w tę pułapkę.
Alert który nikt nie czyta to nie alert — to noise. Dobra observability to mniej kanałów ale precyzyjniej routowane.
Webhook vs Bot API — co kiedy
Slack ma dwa główne API do wysyłania wiadomości:
- Incoming Webhook (najprostsze): URL → POST JSON → wiadomość. Setup: 5 min. Limitacja: jeden URL per kanał, brak interakcji.
- Bot API (pełniejsze): token + scope → wysyłaj do dowolnego kanału, thready, reactions, interactive buttons. Setup: 15-30 min. Wymaga workspace admin approval.
Reguła: jeśli tylko wysyłasz informacje — webhook. Jeśli potrzebujesz interakcji (przyciski "Ack", "Mute 1h", "Reassign") — Bot API.
Routing per priorytet
Zamiast 1 kanału, używaj 3:
- #ax-alerts-critical — pipeline down, dane korumpowane, security incident. Ping @here lub @oncall. Cel: response <15 min.
- #ax-alerts-high — degraded performance, partial failures, parser zaczyna fail-ować. Bez ping'a. Cel: response w godzinach pracy <4h.
- #ax-logs — normal operations, daily summary, scheduled job completed. Read-only mute domyślnie. Cel: refer when needed.
Threshold do critical: tylko gdy action required w <1h. Wszystko inne to high lub logs. Dyscyplina critical → odpowiada na każde critical w 15 min.
Anatomia dobrego alertu
Każda wiadomość alert'u powinna zawierać:
- Severity icon — 🔴 critical, 🟡 high, 🔵 info (jeden glance enough)
- System ID — np.
OPS-25-K7— natychmiast wiadomo czyj system - 1-line summary — co się zepsuło (nie "error", a "parser failed na nike.com — selector .price-now changed")
- Impact — co to znaczy operacyjnie ("0 SKUs collected last 2h, retry queue: 47")
- Direct link — do dashboard / logs / runbook
- Recommended action — najprostszy następny krok
Template praktyczne
Critical alert (parser failed)
🔴 [OPS-25-K7] Parser failed | nike.com
14 selectors broken — likely site redesign
Impact: 0/247 SKUs collected last 90 min
Action: fix parser within 4h
📊 Dashboard: ax.io/ops-25-k7 | 📚 Runbook: ax.io/rb/parser-fail
Daily summary (info)
🔵 [OPS-25-K7] Daily summary | 2026-03-25
✅ 247/247 SKUs collected (100%)
📈 12 prices changed (3 down, 9 up)
⏱️ Total runtime: 4m 32s
📊 Dashboard: ax.io/ops-25-k7
Anti-patterns
Co nie robić:
- Alert per row — "Found 47 new prices" jako 47 osobnych wiadomości. Aggreguj.
- Alert bez kontekstu — "Error" lub "Failed task". Co? Gdzie? Jakie konsekwencje?
- Alert "wszystko OK" — co minutę "system OK". Nikt tego nie czyta, hides real alerts.
- @channel dla normal events — pingi reserved dla critical. Inaczej zespół przestaje reagować.
- Same alert co 5 min — gdy parser failuje przez godzinę, 1 alert + escalate, nie 12.
Snooze + acknowledgment flow
Bot API umożliwia interactive buttons. Praktyczna implementacja:
[Ack]— "wiem o problemie, zajmuję się". Wstrzymuje re-alert'y na 1h.[Mute 4h]— "wiem, fix idzie, nie spam-uj". Wycisza na 4h.[Resolved]— incident closed, opens post-mortem template.[Escalate]— pingi on-call + creates Linear ticket.
Bez tego team żyje w stresie "czy ktoś już to widział?". Z buttons — clear ownership flow.
Sedno
3 kanały (critical / high / logs), severity-first format, 1 alert per incident not per row, acknowledge buttons. Setup pojedynczego pipeline = ~30 min. Setup całego stack-u (5-10 pipeline'ów) = pół dnia. Zwrot inwestycji: pierwsze 2 tygodnie production save 10+ godzin zespołu który nie szuka co się dzieje.