Invia un payload JSON firmato a un endpoint che controlli quando un monitor scatta: campi selezionabili, nuovi tentativi automatici con backoff esponenziale e un registro delle consegne per analizzare ogni evento.
I webhook sono il mattone universale delle integrazioni. Che tu stia instradando gli alert in uno strumento di incident fatto in casa, creando ticket Jira o alimentando un flusso di eventi Datadog, l'endpoint webhook è il punto in cui Site Qwality passa il testimone ai tuoi sistemi.
Ogni consegna è un involucro JSON con il nome dell'evento, una gravità, un ID di consegna e un oggetto data. Per i monitor HTTP, data è il risultato del controllo: ID del monitor, stato, URL controllato, codice HTTP, motivo del guasto e tempi per fase.
Ogni consegna a un'integrazione webhook include un header X-SiteQwality-Signature. È un HMAC-SHA256 calcolato su ID di consegna, timestamp e corpo grezzo della richiesta, uniti da punti, con il segreto di firma del tuo endpoint come chiave. Il timestamp è dentro la firma, quindi un ricevitore che lo verifica può rifiutare una consegna intercettata e rinviata in seguito.
Una consegna fallita viene ritentata con backoff esponenziale, fino a cinque nuovi tentativi in 30 minuti, prima di essere segnata come fallita. In totale sono sei consegne: il primo tentativo e cinque ripetizioni.
Scegli quali campi del risultato del controllo compaiono nel payload, aggiungi fino a dieci chiavi di metadati personalizzate e filtra gli eventi per nome o per gravità minima, così il tuo ricevitore gestisce solo ciò che serve.
Ogni consegna viene registrata con la richiesta inviata, il codice di stato della risposta, un estratto del corpo della risposta e la durata. I record sono conservati per 30 giorni. Consultali e rinvia qualsiasi consegna dalla dashboard o tramite l'API.
Invia lo stesso evento a più endpoint: instrada un alert contemporaneamente a un webhook PagerDuty e a un tuo servizio di audit log.
Se il tuo endpoint non è raggiungibile o restituisce un 5xx, Site Qwality ritenta 10 secondi, 30 secondi, 2 minuti, 8 minuti e 30 minuti dopo il primo tentativo. Un 4xx non viene ritentato: se il tuo endpoint restituisce 404 te lo diciamo invece di inviare la stessa richiesta altre cinque volte. Ogni tentativo viene registrato con lo stato HTTP.
Ogni consegna ha un involucro con ID di consegna, nome dell'evento, gravità, timestamp e
ID del tuo account. Per un monitor HTTP il risultato del controllo si trova sotto
data: ID del monitor, stato, URL controllato, codice HTTP, motivo del
guasto e tempi per fase. Il payload HTTP riporta l'ID del monitor, non il nome.
Gli altri tipi di evento hanno i propri campi data.
La firma copre {delivery_id}.{timestamp}.{raw request body}, non solo il
corpo. ID e timestamp arrivano come header ed entrambi sono dentro il MAC: l'ID
perché è la tua chiave di deduplicazione, il timestamp perché una firma senza di
esso resterebbe riutilizzabile per sempre. Verifica l'età prima del MAC e confronta
in tempo costante.
nuovi tentativi prima che una consegna sia segnata come fallita
webhook in ogni piano, gratuito incluso
ogni consegna registrata con la richiesta completa e un estratto della risposta
timeout per tentativo di consegna, dopo il quale quel tentativo viene abbandonato
La stringa firmata è {delivery_id}.{timestamp}.{raw request body}, unita da punti, e il valore dell'header è v1= seguito dall'HMAC-SHA256 esadecimale di quella stringa con il segreto di firma del tuo endpoint. Il segreto si usa esattamente come ti viene mostrato, senza decodifica base64 e senza togliere prefissi. ID di consegna e timestamp arrivano in X-SiteQwality-Delivery e X-SiteQwality-Timestamp, ed entrambi sono dentro il MAC. Una firma sul solo corpo lascerebbe riutilizzabile una consegna intercettata. Verifica che il timestamp non abbia più di cinque minuti prima di verificare il MAC, e aspettati più di una voce v1= separata da spazio nelle 24 ore dopo la rotazione di un segreto. Lo snippet sopra queste FAQ fa tutto questo.
Quindici eventi: monitor.down, monitor.recover, incident.created, incident.resolved, tls.expiring, dns.expiring, dns.record_change, page_speed.degraded, alert.firing, alert.resolved e cinque eventi del real user monitoring: rum.issue.created, rum.issue.regressed, rum.issue.escalating, rum.alert.firing e rum.alert.resolved. Sono tutti attivi per impostazione predefinita e puoi filtrarli per endpoint, per evento o per gravità minima, così un ricevitore gestisce solo ciò che serve. La forma di data cambia in base al tipo di evento. I due eventi di incidente vanno ai webhook di destinazione impostati su un servizio; queste consegne non sono firmate e non compaiono nel registro delle consegne.
Site Qwality ritenta 10 secondi, 30 secondi, 2 minuti, 8 minuti e 30 minuti dopo il primo tentativo. Sono distanze dal primo tentativo, non intervalli tra un tentativo e l'altro: l'ultimo arriva esattamente dopo 30 minuti. Al massimo sono sei consegne, il primo tentativo più cinque ripetizioni, e una consegna non riuscita 30 minuti dopo il primo tentativo viene segnata come fallita. Puoi poi rinviarla dal registro delle consegne.
Sì, dal registro delle consegne nella dashboard o tramite l'API. Il registro conserva per 30 giorni ogni tentativo con la richiesta inviata, il codice di stato della risposta, un estratto del corpo della risposta e la durata. Un rinvio invia di nuovo il corpo salvato con un nuovo header X-SiteQwality-Delivery, un nuovo timestamp e una nuova firma con il tuo segreto attuale. L'id nel corpo resta quello originale, quindi viene rinviato ciò che fu inviato e non ciò che produrrebbero le impostazioni di oggi.
Sì. I webhook sono inclusi in ogni piano, gratuito incluso.
Uptime, cron, synthetic, log, RUM, incidenti e pagine di stato. Piano gratuito su ogni prodotto.