Monitoreo web con webhooks
Uptimia comprueba sus sitios, certificados y procesos de compra desde fuera de su red, y llama a su endpoint con cada fallo confirmado. Su propio código decide qué ocurre después — abrir un ticket, reiniciar un servicio, alimentar un panel — y cada comprobación envía el mismo formato, así que escribe el gestor una sola vez.
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" }
No un mensaje: un contrato
Todos los demás canales terminan en una persona, y las personas son lectoras indulgentes. El código no lo es — por eso lo interesante nunca es el contenido del mensaje, sino las garantías que hay detrás.
«Algo se rompió» — usted averigua el resto
El texto puede variar entre versiones porque quien lo lee se adapta. En cuanto el software depende de él, esa informalidad se convierte en un fallo de su integración.
Once campos, cinco reintentos, una estructura
Un solo objeto para cada tipo de comprobación: escriba un gestor y ramifique según dos campos. Se reintenta cinco veces antes de descartarse, así que puede haber duplicados — documentados, no descubiertos por sorpresa.
La alerta llega directamente a su código
Una comprobación falla y Uptimia llama a su endpoint con los detalles, ya confirmados. Su propia automatización decide qué ocurre después — aquí, un ticket que se abre solo y se cierra al recuperarse.
Conecte un webhook en tres pasos
No hay ninguna aplicación que autorizar ni ninguna librería que instalar — Uptimia solo necesita una URL a la que llamar y, si el endpoint está protegido, un encabezado que le dé acceso.
Pegue la URL de su endpoint
Eso es todo el registro — una URL pública.
Agregue sus encabezados
Opcional — los encabezados se envían exactamente como los escriba, así un token permite que Uptimia entre por su propia puerta.
Apunte sus monitores hacia él
Elija las comprobaciones que deben llamarlo, y una entrega de prueba confirma la conexión con el formato real.
Registrar un endpoint de webhook
El Centro de ayuda cubre la implementación: agregar la URL, escribir los encabezados personalizados, enviar un POST de prueba e interpretar lo que le dice una entrega fallida.
Todos los tipos de comprobación. Una estructura.
Un certificado a punto de caducar, una tarea cron que nunca llegó a reportarse y un servidor que supera su umbral de CPU llegan todos como el mismo objeto plano. Dos campos los distinguen.
Puentes de chat, filas de base de datos, acciones
En cuanto un incidente es un objeto que su código aceptó, las aplicaciones útiles dejan de parecerse a un simple sistema de alertas.
Los demás canales avisan a una persona.Este avisa a su código.
Toda la plataforma en la prueba gratuita — todo tipo de comprobación, más de 171 sondas y cada incidente confirmado llega como un objeto suyo.
Las garantías de entrega, por escrito
Nadie puede escribir un gestor fiable a partir de «le enviaremos una notificación». Estas son las garantías reales.
Al menos una vez, con cinco reintentos
Diez segundos para responder, y cualquier 2xx cuenta como aceptado. Cualquier otra cosa vuelve a la cola y se reintenta cinco veces, cada espera un minuto más larga que la anterior, y luego se descarta — así que responda primero y haga el trabajo después.
Un objeto plano, once claves
Sin anidamiento, sin envoltorio, sin un esquema que cambie según el tipo de comprobación. Dos campos distinguen los casos; los otros nueve nunca cambian de significado — incluido monitor_notes, la línea de runbook que dejó quien configuró el monitor.
Una avalancha agrega una clave
Los monitores que fallan juntos se convierten en una sola solicitud con un objeto de grupo adicional — miembros, recuentos, reconocimiento. Los gestores que lo ignoran siguen funcionando.
Sus encabezados, tal cual
Se envían literalmente, así un token bearer o un secreto compartido funcionan. No hay firma del cuerpo — compruebe el encabezado en su servidor y mantenga la URL en secreto.
Dónde se negará a enviar
Solo http(s) públicos; se rechazan los rangos de loopback y privados. La dirección se resuelve una vez y queda fijada, las redirecciones se ignoran, TLS se verifica.
Sin enlace para reconocer — a propósito
Los canales que lee una persona llevan un enlace firmado que detiene el escalado. Las máquinas reciben los datos y nada más — un flujo de registros que puede silenciar un aviso de guardia, tarde o temprano lo hará.
Cómo funcionan los webhooks de monitoreo
Uptimia comprueba sus sitios web desde más de 171 sondas y, cuando una comprobación falla, envía una solicitud HTTP POST con un cuerpo JSON a cualquier URL que registre. El mismo objeto plano llega para cada tipo de comprobación — qué monitor, qué pasó, cuándo y durante cuánto tiempo — así que un solo gestor los cubre todos, y las entregas fallidas se reintentan.
El error que todo el mundo comete el primer día
Las recuperaciones, los avisos y las pruebas comparten un mismo endpoint. monitor_status es down, up o test; severity es critical o trouble, y vacío en una recuperación. Ramifique según ambos campos.
Confirmado antes de que su código se entere
Una automatización es tan fiable como el disparador que la activa. Una comprobación web nunca alerta basándose en la opinión de una sola sonda — un fallo sospechoso se vuelve a comprobar primero desde otras sondas.
Once campos, en cada evento
Lo que siempre está presente, y qué contiene.
Ver todos los canales de alertas →| Campo | Ejemplo | Qué contiene |
|---|---|---|
| id | 4172 | El id numérico del monitor dentro de Uptimia |
| monitor_type | uptime | Qué tipo de comprobación se disparó |
| monitor_name | Dispatch API | El nombre que le diste (el nombre del sitio en las comprobaciones de disponibilidad) |
| monitor_unique_id | dispatch-api-eu | Tu propio identificador — la clave para unir tablas |
| monitor_status | down | down, up o test |
| severity | critical | critical o trouble — vacío en una recuperación |
| incident_start_time | 2026-07-24T02:17:04+02:00 | ISO 8601, zona horaria de la cuenta |
| incident_end_time | 2026-07-24T02:31:07+02:00 | Vacío mientras el incidente está abierto |
| incident_duration_seconds | 843 | Cero hasta que el incidente se cierra |
| message | *ALERT*: Project … is DOWN | El resumen de una línea que reciben los demás canales |
| monitor_notes | Failover: drain eu-west-2 first | La nota del monitor — vacía si nadie escribió ninguna |
Preguntas frecuentes sobre webhooks personalizados
01¿Qué envían exactamente?+
02¿Cómo autentico la solicitud?+
03¿Qué pasa si mi endpoint va lento o está caído?+
04¿Puedo llegar a recibir el mismo evento dos veces?+
05¿Puedo apuntarlo a localhost o a una dirección interna?+
06¿Siguen las redirecciones?+
07¿Qué llega cuando fallan varios monitores a la vez?+
08¿Puede mi gestor reconocer o responder?+
09¿Qué envía realmente «Enviar prueba»?+
10¿Cuántos endpoints puedo tener, y está incluido?+
Una URL, todos los incidentes reconocidos
Registre un endpoint, asígnelo a los monitores que importan y cada fallo reconocido llegará como un objeto que sus sistemas pueden archivar y usar para actuar.