L’alert arriva alla persona giusta, non nel rumore.
Il tuo stack di monitoraggio lancia un webhook; SendNomi instrada l’alert al team giusto in base a severità ed etichette, distribuisce i digest a orario programmato e gestisce la risposta agli incidenti a registro, dall’inizio alla fine. L’email operativa o è rumore o è un salvavita — la differenza sta nella regola di routing.
Non rumore — una sola email al team giusto.
Un superamento di soglia in Prometheus o un allarme di Grafana arriva come webhook; la regola guarda severità (P1–P3) ed etichette per individuare il team di destinazione. L’ingegnere on-call riceve un’email formattata con un riepilogo del contesto e ogni alert finisce in un registro con timestamp. SendNomi si mette davanti al tuo stack di monitoraggio esistente — nessun SDK richiesto.
- Evento Un superamento di soglia o un allarme arriva come webhook.
POST /webhooks/alerts - Regola Il match su severità + etichette individua il team di destinazione.
severity=P1 → team: on-call - Invio Un’email di alert formattata con un riepilogo del contesto.
template: alert-context - Registro Chi, quando, perché — un log con timestamp.
retention: 12 mesi
Il rumore si deposita in un unico report mattutino.
I digest giornalieri e settimanali si generano da soli su trigger cron: un report basato su template arriva al team come singola email, senza raccolta manuale. Una nuova rotta, una finestra di manutenzione o una nota di release viaggia sullo stesso canale — pubblicata in un clic a un pubblico basato sui ruoli, così tutto il team la riceve nello stesso momento.
- Digest giornaliero dei log Ogni mattina un report basato su template raggiunge il team.
trigger: cron · giornaliero - Digest settimanale Le metriche della settimana si uniscono in un’unica email.
trigger: cron · settimanale - Annuncio di sistema Deploy, manutenzione, nuova rotta — pubblicato in un clic.
target: basato sui ruoli
Un incidente non si risolve soltanto: si annuncia, si traccia, si rivede.
Nel momento in cui si apre un allarme P1, l’ingegnere on-call ha già il riepilogo del contesto; gli stakeholder ricevono lo stato da un’unica fonte e le note di avanzamento partono da sole a intervalli definiti mentre la risoluzione è in corso. Alla chiusura dell’incidente, la finestra di impatto e il riepilogo vengono distribuiti; la timeline della revisione post-incidente si compila da sola a partire dall’audit log. Nessun passaggio esce dal registro.
- RILEVAMENTO Incidente aperto
Allarme P1; l’ingegnere on-call riceve subito un’email con il riepilogo del contesto.
- ANNUNCIO Avviso agli stakeholder
I team coinvolti e i manager ricevono lo stato da un’unica fonte.
- AGGIORNAMENTO Nota di avanzamento
Aggiornamenti di stato automatici a intervalli definiti mentre la risoluzione è in corso.
- CHIUSURA Nota di risoluzione
La finestra di impatto e un breve riepilogo arrivano a tutti gli stakeholder.
- REVISIONE Report post-incidente
La timeline si compila da sola a partire dall’audit log.
I primi secondi di un alert P1.
Come un alert entra come webhook e diventa un record tracciabile in una configurazione rappresentativa — i valori di latenza si riferiscono a una configurazione tipica e variano con la complessità delle regole.
L’email di alert include un riepilogo del contesto: quale servizio, quale soglia, da quando.
Il tuo primo invio in pochi minuti.
Crea il tuo account gratuito — 500 invii al mese, per sempre.