Come ti informiamo o avvisiamo
Un outage vale la pena rilevarlo solo se le persone giuste ne vengono informate. Inviamo notifiche dove il tuo team è già presente e ai tuoi sistemi tramite webhooks.
I canali
Ogni canale riceve lo stesso messaggio: quale monitor, da quando e perché. Qui sotto trovi un elenco dei canali disponibili.
-
Email Ogni piano
Un messaggio a qualsiasi indirizzo. L'indirizzo e-mail deve essere confermato una volta.
-
Webhook (POST) Ogni piano
Un corpo JSON con i dati rilevanti inviato a un URL che hai fornito. Per la tua automazione: apri un ticket, avvisa una persona, cambia una luce di stato.
-
Webhook (GET) Ogni piano
Gli stessi campi del webhook POST ma ora come parametri di query, per un ricevitore che accetta una richiesta GET.
-
PagerDuty Starter e superiori
Un incidente tramite l'Events API v2, aperto su un outage e risolto al recovery, così l'escalation di PagerDuty lo gestisce da lì.
-
Slack Pro e Business
Un messaggio in un canale, rosso per offline e verde per tornato online, tramite un webhook.
-
Microsoft Teams Pro e Business
Lo stesso messaggio in un canale Teams, tramite un webhook.
-
Discord Pro e Business
Lo stesso messaggio in un canale Discord, tramite un webhook del canale.
-
Telegram Pro e Business
Lo stesso messaggio in una chat, tramite il tuo bot.
Chi sente cosa, e quando
Confermati prima
Non viene inviato nulla sulla base di una sola sonda. Un errore diventa un outage quando le sonde di tre continenti sono d'accordo, quindi un alert significa che il sito è offline e non un problema di rete.
Regole ed escalation
Una regola descrive chi viene informato su quali monitor e a che ora. Metti la lista di reperibilità in un gruppo di contatti con un ritardo per membro. Questo funziona come la tua politica di escalation.
Tornato online, detto una volta
Tutti coloro che sono stati informati dell'outage vengono avvisati quando finisce, con la durata. Non ti sveglieremo per dirti che l'outage è terminato.
Testa prima che ti serva
Ogni indirizzo ha un pulsante che invia un test attraverso lo stesso percorso di un vero avviso, formulato in modo che non possa essere scambiato per un vero outage.
Il webhook, per i tuoi sistemi
Un indirizzo webhook è una tua URL. La chiamiamo quando un outage è confermato, quando si riprende e quando premi test. POST invia i campi come corpo JSON; GET li invia come parametri di query. La URL è memorizzata criptata e non viene mai più mostrata per intero, perché chiunque la possieda può inviarle dati.
| Campo | Cosa contiene |
|---|---|
| reason | down quando un outage è confermato, recovery quando finisce, test quando qualcuno ha premuto il pulsante |
| monitor | Il nome del monitor |
| monitor_id | Il suo id |
| target | Cosa controlla: la URL, l'host o il nome |
| type | Il tipo di controllo, come un nome breve tipo https, dns o ssl_cert |
| cause | Perché ha fallito, in poche parole, quando lo sappiamo |
| error_class | La stessa cosa come un nome breve su cui un programma può ramificarsi, tipo timeout, connection o certificate_expired |
| started | Quando è iniziato l'outage |
| confirmed_at | Quando il fallimento è stato confermato |
| confirmed_from | I continenti che lo hanno confermato, come elenco di nomi. |
| degraded | true quando il monitor è lento o perde pacchetti invece di essere down |
| resolved | Quando è finito, come un timestamp ISO 8601, su una recovery |
| duration | Quanto è durato, in parole, su una recovery |
| incident_id | L'id dell'incidente, lo stesso sull'outage e sulla sua recovery |
Un campo senza valore è null nel JSON e viene omesso in un GET. Devi rispondere con uno status inferiore a 400. Qualsiasi altra cosa conta come una consegna fallita e viene ritentata dopo 30 secondi, 2 minuti e 10 minuti, poi abbandonata: un alert che non è arrivato entro un quarto d'ora è storia, non notizia.