Monitoraggio dei siti web: webhook
Uptimia controlla i tuoi siti, certificati e flussi di checkout dall’esterno della tua rete e chiama il tuo endpoint a ogni guasto confermato. Il tuo codice decide cosa fare dopo — aprire un ticket, riavviare un servizio, alimentare una dashboard — e ogni controllo invia lo stesso formato, così scrivi l’handler una volta sola.
Authorization: Bearer •••••••••••••••• Content-Type: application/json { "id": 3517, "monitor_type": "uptime", "monitor_name": "Checkout — caldmont.com", "monitor_unique_id": "checkout-prod", "monitor_status": "down", "severity": "critical", "incident_start_time": "2026-07-30T11:47:12+02:00", "incident_end_time": "", "incident_duration_seconds": 0, "message": "*ALERT*: Project Checkout — caldmont.com is DOWN", "monitor_notes": "Failover: drain eu-west-2 first" }
Non un messaggio, un contratto
Ogni altro canale finisce da una persona, e le persone sono lettori indulgenti. Il codice no — ed è per questo che la parte interessante non è mai il payload, ma le garanzie che ci sono dietro.
“Qualcosa si è rotto” — al resto ci pensi tu
Il testo può cambiare da una versione all’altra perché il lettore si adatta. Nel momento in cui un software ne dipende, quell’informalità diventa un difetto nella tua integrazione.
Undici campi, cinque tentativi, una struttura
Un solo oggetto per ogni tipo di controllo: scrivi un handler, dirama la logica su due campi. Viene riprovato cinque volte prima di essere scartato, quindi i duplicati sono possibili — documentati, non scoperti per caso.
L’avviso arriva dentro il tuo codice
Un controllo fallisce e Uptimia chiama il tuo endpoint con i dettagli, già confermati. La tua automazione decide cosa fare dopo — qui, un ticket che si apre da solo e si chiude al ripristino.
Collega un webhook in tre passi
Nessuna app da autorizzare e nessuna libreria da installare — Uptimia ha bisogno solo di un URL da chiamare e, se l’endpoint è protetto, di un header che gli permetta di entrare.
Incolla l’URL del tuo endpoint
Ecco fatta tutta la registrazione — un solo URL pubblico.
Aggiungi i tuoi header di autenticazione
Facoltativo — gli header vengono inviati esattamente come li scrivi, così un token fa passare Uptimia dalla tua porta.
Punta i tuoi Monitor su di esso
Scegli i controlli che devono chiamarlo, e una consegna di prova verifica il collegamento con il formato reale.
Registra un endpoint webhook
Il Centro assistenza copre l’implementazione: aggiungere l’URL, scrivere gli header personalizzati, inviare una POST di prova e interpretare cosa ti sta dicendo una consegna fallita.
Ogni tipo di controllo. Una sola struttura.
Un certificato in scadenza, un cron job che non si è mai fatto sentire e un server oltre la sua soglia di CPU arrivano tutti come lo stesso oggetto piatto. Due campi li distinguono.
Ponti verso la chat, righe di database, azioni automatiche
Una volta che un incidente è un oggetto che il tuo codice ha accettato, gli usi utili smettono di somigliare a un semplice avviso.
Gli altri canali lo dicono a una persona.Questo lo dice al tuo codice.
Tutta la piattaforma nella prova gratuita — ogni tipo di controllo, oltre 171 sonde, e ogni incidente confermato consegnato come un oggetto che possiedi tu.
Le garanzie di consegna, messe per iscritto
Nessuno può scrivere un handler affidabile basandosi su “ti invieremo una notifica”. Queste sono le garanzie reali.
At-least-once, con cinque tentativi
Dieci secondi per rispondere, e qualsiasi 2xx conta come accettato. Tutto il resto viene rimesso in coda e riprovato cinque volte, con un’attesa che cresce di un minuto ogni volta, poi scartato — quindi rispondi prima e fai il lavoro dopo.
Un oggetto piatto, undici chiavi
Nessun annidamento, nessuna busta, nessuno schema che cambia in base al tipo di controllo. Due campi distinguono i casi; gli altri nove non cambiano mai significato — incluso monitor_notes, la riga da runbook che chi ha configurato il Monitor ha lasciato.
Un’ondata aggiunge una chiave
I Monitor che falliscono insieme diventano un’unica richiesta con un oggetto group aggiuntivo — membri, conteggi, presa in carico. Gli handler che lo ignorano continuano a funzionare.
I tuoi header, trasmessi senza modifiche
Inviati parola per parola, così un bearer token o un segreto condiviso funzionano. Non c’è nessuna firma del corpo — verifica l’header lato server, e mantieni segreto l’URL.
Dove si rifiuterà di inviare
Solo http(s) pubblico; loopback e intervalli privati vengono rifiutati. L’indirizzo viene risolto una sola volta e bloccato, i redirect vengono ignorati, il TLS viene verificato.
Nessun link per prendere in carico — di proposito
I canali che legge una persona portano un link firmato che ferma la scaletta. Le macchine ricevono i fatti e nient’altro — una pipeline di log che può silenziare un pager, prima o poi lo farà.
Come funzionano i webhook di monitoraggio
Uptimia controlla i tuoi siti web da oltre 171 sonde esterne e, quando un controllo fallisce, invia una richiesta HTTP POST con un corpo JSON a qualsiasi URL tu abbia registrato. Lo stesso oggetto piatto arriva per ogni tipo di controllo — quale Monitor, cosa è successo, quando e per quanto tempo — così un solo handler li copre tutti, e le consegne fallite vengono riprovate.
Il bug che tutti scrivono il primo giorno
Ripristini, avvisi di anomalia e test condividono un unico endpoint. monitor_status vale down, up o test; severity vale critical o trouble, ed è vuoto al ripristino. Dirama la logica su entrambi.
Confermato prima che il tuo codice lo sappia
Un’automazione vale quanto il segnale che la fa scattare. Un controllo web non genera mai un avviso sul giudizio di una sola sonda — un sospetto guasto viene prima riverificato da altre sonde.
Undici campi, ogni evento
Cosa è sempre presente, e cosa contiene.
Guarda tutti i canali di avviso →| Campo | Esempio | Cosa contiene |
|---|---|---|
| id | 4172 | L’id numerico del Monitor all’interno di Uptimia |
| monitor_type | uptime | Quale tipo di controllo si è attivato |
| monitor_name | Dispatch API | Il nome che gli hai dato (il nome del sito per i controlli uptime) |
| monitor_unique_id | dispatch-api-eu | Il tuo identificatore — la chiave su cui fare il join |
| monitor_status | down | down, up o test |
| severity | critical | critical o trouble — vuoto al ripristino |
| incident_start_time | 2026-07-24T02:17:04+02:00 | ISO 8601, fuso orario dell’account |
| incident_end_time | 2026-07-24T02:31:07+02:00 | Vuoto finché l’incidente è aperto |
| incident_duration_seconds | 843 | Zero finché l’incidente non si chiude |
| message | *ALERT*: Project … is DOWN | Il riepilogo in una riga che ricevono anche gli altri canali |
| monitor_notes | Failover: drain eu-west-2 first | La nota del Monitor — vuota se nessuno l’ha scritta |
FAQ sui webhook personalizzati
01Cosa inviate esattamente?+
02Come autentico la richiesta?+
03Cosa succede se il mio endpoint è lento o down?+
04Riceverò mai lo stesso evento due volte?+
05Posso puntarlo su localhost o su un indirizzo interno?+
06Seguite i redirect?+
07Cosa arriva quando più Monitor falliscono insieme?+
08Il mio handler può prendere in carico, o rispondere?+
09Cosa invia esattamente “Invia test”?+
10Quanti endpoint posso avere, ed è incluso?+
Un solo URL, ogni incidente confermato
Registra un endpoint, collegalo ai Monitor che contano, e ogni guasto confermato arriverà come un oggetto che i tuoi sistemi possono archiviare e su cui possono agire.