Avvisi e notifiche

Gli avvisi partono attraverso i canali, che si aggiungono nella pagina notifiche. Ogni canale sceglie quali monitor ed eventi riceve, e può aspettare o ripetere. invia test prova un canale prima di salvarlo.

Ogni avviso dice quale monitor, cosa è successo e, per gli avvisi di down, la causa per località e un link alla diagnostica. Le email usano la stessa grafica dell'interfaccia web, in chiaro e scuro.

Notifiche desktop: nella pagina notifiche ognuno può attivare anche le notifiche del browser. Finché una scheda di pingtxt è aperta, anche in background, quel browser avvisa quando un monitor va down o torna up. Non viene inviato nulla ad altri.

Ogni canale ha un ambito e degli eventi:

• ambito: tutti i monitor (anche quelli aggiunti in seguito), oppure i monitor di alcuni gruppi e tag, oppure nessuno (solo i monitor collegati uno per uno).
• eventi: down (con i suoi promemoria), up (ripristino, solo ai canali che hanno ricevuto l'avviso), degraded (alcune località falliscono o sono lente, e quando finisce; spento di default), cert_expiry, domain_expiry e agent_offline (avvisi di agent offline: riguarda gli agent, quindi ignora l'ambito e i collegamenti dei monitor).

Un monitor si può anche collegare a un canale uno per uno, dal canale (il suo elenco di monitor) o dal modulo del monitor (notifiche). Il collegamento ha eventi propri e vince sull'ambito, quindi aggiunge un monitor, cambia cosa invia o esclude il monitor da un canale su tutti i monitor.

Ogni canale ha due impostazioni facoltative, in minuti:

• invia dopo: il canale riceve l'avviso solo se dopo questo tempo il monitor è ancora down (0 = subito). Aggiungi un secondo canale (il telefono di reperibilità, l'email di un responsabile) con 15 o 30 minuti per l'escalation dei disservizi lunghi: i problemi brevi non lo raggiungono mai, e riceve il ripristino solo se ha ricevuto l'avviso.
• ripeti ogni: il canale riceve un promemoria STILL DOWN a questo intervallo finché il monitor resta down (0 = una volta sola, almeno 5). I webhook includono reminder (1, 2, ...) e down_since (unix ms).

I tempi contano da quando si è aperto l'incidente. Quello che ogni canale ha ricevuto viene salvato con l'incidente, quindi un riavvio non ripete né salta avvisi.

Nella pagina manut pianifica le finestre in cui gli avvisi devono tacere: singole o ricorrenti (ogni giorno, settimana o mese, in qualsiasi fuso orario), per alcuni o tutti i monitor, o interi gruppi e tag.

Durante una finestra i monitor risultano in manutenzione: i controlli continuano, ma non si aprono incidenti, non partono avvisi e quei controlli non contano per l'uptime. Un monitor ancora down quando la finestra finisce riceve l'avviso in quel momento.

pingtxt tiene d'occhio il certificato TLS dei monitor https e la registrazione del loro dominio (RDAP, con WHOIS per i registri senza RDAP, come il .it). Attiva l'uno o l'altro per monitor. Le soglie in giorni si impostano in impostazioni → monitor (predefinite 14/7/3/1 per i certificati, 30/14/7/1 per i domini): un avviso per ogni soglia superata, uno alla scadenza e uno al rinnovo. I canali li ricevono con gli eventi cert_expiry e domain_expiry.

I report periodici, nella pagina notifiche, mandano via email uptime, incidenti e tempi di inattività dell'ultima settimana (ogni lunedì) o dell'ultimo mese (il giorno 1), per gruppo di monitor, a confronto con il periodo precedente. Scegli i canali email, eventualmente alcuni gruppi, l'ora e il fuso orario. anteprima mostra un report e invia ora ne manda uno prima di attivarli.

I webhook ricevono un body JSON con monitor_id, monitor, target, status, cause e at (unix ms), più:

Usa invia test per vedere un contenuto reale sul tuo endpoint.