Configurare alert email per errori 500

Gli errori HTTP 500 sono spesso il primo sintomo di un sito WordPress fuori servizio. Con WP Error Monitor puoi configurare alert email automatici che ti avvisano in tempo reale quando un visitatore incontra un 500, permettendoti di intervenire prima che il problema scali. In questa guida vediamo come impostare regole, destinatari e soglie.

Quando inviare un'alert email

Gli alert email funzionano bene per eventi critici ma non frequenti: un 500 isolato può essere ignorato in fase di rumble, mentre 10 errori 500 in 60 secondi sono sicuramente una incidence da gestire. La regola d’oro è definire una soglia (es. 5 errori in 5 minuti) e un cooldown (es. 30 minuti) per evitare di intasare la casella. WP Error Monitor supporta entrambi i parametri con granularità per sito.

Anatomia di un'alert

L’email contiene: oggetto con sito e tipo di errore, riassunto con conteggio e finestra temporale, URL coinvolto, IP del visitatore (mascherato per GDPR), stack trace troncato e link diretto all’evento sul CRM. Il template è personalizzabile da admin: puoi aggiungere il logo cliente, una call-to-action e un piè di pagina con instruzioni di escalation.

Multi-destinatario e ruoli

Puoi indicare uno o più destinatari per ogni regola. Tipicamente impostiamo: webmaster cliente in CC, on-call G Tech Group in TO e gruppo team-wordpress in BCC. In alternativa puoi creare una mailing list condivisa (es. alert-clienteX@gtechgroup.it) e indicare quella, semplificando la gestione dei turni.

Template HTML personalizzati

Il template di default dell’alert è minimale: oggetto + corpo testuale. Puoi sostituirlo con un template HTML personalizzato che include il logo cliente, una sezione di azioni rapide (link per acknowledgement, snooze, escalation) e un piè di pagina con link al runbook. Il sistema supporta variabili placeholder (es. site_name, error_message, stack_trace, first_seen) che vengono sostituite al momento dell’invio. Salva più template per usi diversi.

Escalation policy

Per incident critici una sola email non basta: configura escalation a più step. Step 1 (0min): email a on-call primario. Step 2 (15min se non ack): SMS a on-call secondario via Twilio. Step 3 (30min se non ack): chiamata vocale a manager via servizio voice. WP Error Monitor traccia gli stati di ack: se nessuno risponde, scatena automaticamente lo step successivo, evitando incident che restano scoperti per ore.

Webhook custom come fallback

Se il provider email destinatario blocca temporaneamente le notifiche (rate limit, reputation issue), gli alert non arrivano. WP Error Monitor supporta webhook come canale fallback: se l’invio email fallisce dopo 3 retry, scatena un POST a un'endpoint custom (es. webhook generico che pinga PagerDuty/Opsgenie). Così' la chain di notifica è resiliente: email primaria, webhook secondario, SMS terziario. Per setup webhook fallback, vai a 'Notifiche > Canali > Fallback chain' e definisci ordine. I delay tra step sono configurabili (default 5min). La storia di delivery è visibile in 'Audit log notifiche'.

Throttling intelligente per spike

Durante un'incident, la stessa email può arrivare 50 volte se l’errore si ripete. WP Error Monitor implementa throttling intelligente: il primo evento triggera notifica immediata, le ripetizioni nei successivi 5 minuti aggiornano il counter dell’email già inviata (via email reply update se client lo supporta), oltre i 5 minuti viene inviato un 'digest' aggregato. Così' eviti casella allagata. Algoritmo dettagliato: per ogni pattern (hash del messaggio + file + line), traccia 'last_notification_at' e 'event_count_since'. Se delta < 5min, no notifica; se delta >= 5min e count > 0, invia digest.

Esempio di policy alert per cliente

Una policy alert email tipica per un cliente con sito ecommerce WordPress: errori 500 su /checkout = alert immediato a webmaster + on-call G Tech; errori 500 su altre pagine = alert al solo webmaster; errori 4xx = nessun'alert (rumore); warning PHP = digest settimanale; security pattern (try injection, brute force) = alert immediato anche se non genera errore. Questa segmentazione mantiene basso il volume di notifiche evitando alert fatigue, ma assicura escalation veloce sui pattern davvero critici per il business del cliente.

Procedura passo-passo

1. Apri 'WP Error Monitor > Impostazioni > Notifichè nel CRM.
2. Clicca 'Nuova regola' e seleziona il sito interessato.
3. Imposta condizione: 'HTTP status code = 500' e soglia '5 eventi in 5 minuti'.
4. Imposta canale 'Email’ e inserisci i destinatari separati da virgola.
5. Definisci cooldown a 30 minuti per evitare flood.
6. Personalizza oggetto e corpo del template se necessario.
7. Salva e usa il pulsante 'Test' per inviare una mail di prova.
8. Genera un 500 controllato (es. eccezione di test) e verifica la ricezione.
9. Apri 'Template email’ e clona il default.
10. Imposta escalation policy nel pannello 'Notifiche > Escalation'.

Errori comuni e come risolverli

• Email non arriva: Controlla la coda SMTP del CRM e i log Postfix; verifica che il dominio destinatario non blocchi i messaggi automatici.
• Troppe email duplicate: Aumenta il cooldown o accorpa le regole per sito; abilita 'digest modè che invia un riepilogo ogni 15 minuti.
• Mancano eventi nel grafico ma arrivano email: Cache lato dashboard: forza refresh e controlla il filtro temporale.
• Template HTML rotto in alcuni client: Inline CSS richiesto: usa tool come Premailer per inlining automatico.
• Escalation non scatta: Manca configurazione provider SMS/voice: verifica credenziali Twilio.

Domande frequenti

D: Posso filtrare per URL?
R: Sì, usa il campo 'request_uri regex' per limitare alert a specifici endpoint (es. solo /checkout).

D: Le email sono GDPR compliant?
R: L’IP visitatore è troncato (ultimi due ottetti rimossi) e i dati personali eventuali sono mascherati prima dell’invio.

D: Come gestisco il turno notte?
R: Crea due regole con destinatari diversi e attivazione su fasce orarie tramite il campo 'active_hours'.

D: Posso usare un SMTP esterno?
R: Sì, configura SMTP del CRM: tipicamente SendGrid o Mailgun per deliverability.

D: E se la casella destinatario è piena?
R: Il sistema riceve bounce e marca il destinatario come 'invalido': non spamma più su quell’indirizzo.

Hai bisogno di aiuto?

Se vuoi affidare il monitoraggio WordPress al team di G Tech Group, scrivici tramite il modulo di contatto.