Come configurare alert di downtime efficaci (senza alert fatigue)

Essere avvisati quando il sito va giù è fondamentale. Ricevere 47 notifiche sullo stesso problema su 5 canali no. La differenza tra un sistema di alerting ben configurato e uno rumoroso è tra un team che risponde bene e uno che finisce per ignorare tutto.

Il problema dell'alert fatigue

L'alert fatigue è reale, pericolosa e più comune di quanto si pensi. Quando i team ricevono troppe notifiche, iniziano a ignorarle — anche quelle critiche. Oltre il 30% degli alert in molte organizzazioni viene ignorato o non gestito. Non è un problema di persone; è di configurazione.

L'obiettivo è semplice: ogni alert deve essere azionabile, e ogni problema azionabile deve generare un alert. Tutto il resto è rumore.

Scegliere i canali di alert

Ogni canale ha uno scopo. Ecco come ragionarci:

Slack / Discord / Teams

Ideali per: consapevolezza di team, alert non critici, coordinamento durante gli Incident.

Le piattaforme di messaggistica tengono informato il team, ma non sono affidabili per svegliarti alle 3. I messaggi si perdono, le notifiche si silenziano, i canali diventano rumorosi.

Usa Slack per:

• Avvisi di performance degradata
• Notifiche di risoluzione (così il team sa che il problema è risolto)
• Riepiloghi giornalieri/settimanali di uptime
• Coordinamento durante outage attivi

Email

Ideale per: tracciato, escalation, aggiornamenti agli stakeholder.

L'email è permanente e ricercabile: ottima per audit trail e comunicazione verso stakeholder. Ma è troppo lenta per outage urgenti — pochi controllano l'email in tempo reale.

Usa email per:

• Report e riepiloghi degli Incident
• Alert di violazione SLA alla direzione
• Report settimanali di uptime
• Avvisi non urgenti di degradazione performance

Webhook

Ideali per: automazione, flussi custom, integrazione con la toolchain.

I webhook sono il canale più flessibile. Quando un Monitor rileva un problema, un webhook può:

• Creare un ticket in Jira o Linear
• Attivare un Incident su PagerDuty
• Avviare uno script di remediation
• Pubblicare su una dashboard custom
• Aggiornare automaticamente una Status Page

Usa webhook per:

• Collegamento a piattaforme di incident management
• Risposte automatizzate
• Routing di notifiche personalizzato
• Integrazione con tool interni

SMS / telefonate

Ideali per: alert critici che devono svegliarti alle 3 del mattino.

Riserva SMS e chiamate a problemi davvero critici — outage completi di produzione che richiedono intervento umano immediato. Se usi questo canale per meno, la gente lo silenzia e fallisce quando serve davvero.

Best practice per la configurazione degli alert

1. Conferma prima di avvisare

Un singolo check fallito non è un outage. Blip di rete, picchi di carico ed errori transitori succedono spesso. Configura i Monitor per richiedere 2–3 fallimenti consecutivi prima dell'alert.

Questo elimina la maggior parte dei falsi positivi senza ritardare in modo significativo il rilevamento di outage reali. Con intervallo 30 s e 2 fallimenti consecutivi, un outage reale viene notato entro 60 secondi — abbastanza veloce per quasi ogni situazione.

2. Suddividi i servizi in tier

Non tutti i servizi meritano la stessa intensità di alerting. Crea tier:

Tier 1 — Critical (fatturato / prodotto core)

• Intervallo check: 15–30 s
• Canali: Slack + Webhook (PagerDuty) + SMS
• Conferma: 2 fallimenti
• Esempi: applicazione principale, API, authentication, pagamenti

Tier 2 — Important (servizi di supporto)

• Intervallo: 60 s
• Canali: Slack + Email
• Conferma: 3 fallimenti
• Esempi: documentazione, blog, pannello admin, tool interni

Tier 3 — Nice-to-have (non critici)

• Intervallo: 5 minuti
• Canali: Email
• Conferma: 3 fallimenti
• Esempi: staging, preview di sviluppo, micrositi a basso traffico

3. Imposta soglie sul response time

Non limitarti ai fallimenti completi. Configura alert per degradazione performance:

• Warning: response time > 2× la media baseline
• Critical: response time > 5× la media baseline

Un rallentamento graduale spesso precede un outage totale. Intercettarlo presto dà tempo per indagare ed evitare del tutto l'outage.

4. Raggruppa alert correlati

Se l'applicazione principale è giù, probabilmente falliscono anche API, webhook e CDN. Non servono cinque catene di alert separate per un solo Incident.

Usa raggruppamento o dipendenze: quando api.example.com e app.example.com vanno giù insieme, un alert basta.

5. Includi contesto negli alert

Un alert che dice «Monitor giù» è meno utile di uno che dice:

CRITICO: api.example.com è DOWN3 check consecutivi falliti da US-East, EU-West, AP-SoutheastUltimo status code: 503Response time: Timeout (30s)Durata finora: 2 minutiStatus Page: https://status.example.com

Messaggi chiari riducono il tempo alla diagnosi. Includi nome Monitor, location, motivo del fallimento, durata e link alle dashboard.

6. Definisci percorsi di escalation

Se il primo risponditore non conferma l'alert entro 5–10 minuti, scala:

1. Immediato: on-call via Slack + webhook
2. 5 minuti: on-call via SMS
3. 15 minuti: engineering manager via telefono
4. 30 minuti: VP Engineering

L'escalation evita che problemi critici cadano nel vuoto se qualcuno è via dalla scrivania, in riunione o dorme.

7. Invia notifiche di risoluzione

Quando un Monitor si riprende, notifica gli stessi canali che hanno ricevuto l'alert. Così:

• Il team sa che il problema è risolto
• Hai la durata totale del downtime
• Chiudi il cerchio sull'Incident
• Eviti indagini su problemi già risolti

Errori da evitare

Alert su ogni ambiente: non inviare alert da produzione per staging o sviluppo. Se lo staging è giù, spesso è voluto.

Troppi canali per evento: massimo 2–3 canali per tier di alert. Se mandi a Slack, email, SMS, Discord e webhook per ogni fallimento, crei rumore, non copertura.

Nessuna finestra di manutenzione: se fai deploy ogni martedì, sopprimi gli alert durante la finestra. Il downtime pianificato non è un Incident.

Ignorare le notifiche di recovery: se vieni avvisato solo quando qualcosa si rompe, devi controllare manualmente se è tornato tutto ok. Abilita sempre le notifiche di ripristino.

Conclusione

Un alerting efficace riguarda il rapporto segnale/rumore. Ogni alert deve significare «qualcosa è rotto e qualcuno deve intervenire». Se il team ignora gli alert, il problema non è disciplina — è configurazione.

Parti dalle basi: servizi critici, conferma prima dell'alert, tier appropriati, canali giusti. Affina nel tempo in base a cosa funziona.

Configura alert intelligenti in pochi minuti. Inizia gratis — email, Slack e webhook inclusi in ogni piano.