Monitorización web con webhooks
Uptimia comprueba tus sitios, certificados y procesos de compra desde fuera de tu red, y llama a tu endpoint con cada fallo confirmado. Tu 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 escribes 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 es un mensaje, es 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 ha roto» — tú averiguas 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 tu integración.
Once campos, cinco reintentos, una estructura
Un solo objeto para cada tipo de comprobación: escribe un gestor y ramifica 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 tu código
Una comprobación falla y Uptimia llama a tu endpoint con los detalles, ya confirmados. Tu propia automatización decide qué ocurre después — aquí, un ticket que se abre solo y se cierra al recuperarse.
Conecta 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, una cabecera que le dé acceso.
Pega la URL de tu endpoint
Eso es todo el registro — una URL pública.
Añade tus cabeceras de autenticación
Opcional — las cabeceras se envían exactamente como las escribas, así un token permite que Uptimia entre por tu propia puerta.
Apunta tus monitores hacia él
Elige 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: añadir la URL, escribir las cabeceras personalizadas, enviar un POST de prueba e interpretar lo que te dice una entrega fallida.
Todos los tipos de comprobación. Una sola 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 automatizadas
En cuanto un incidente es un objeto que tu código ha aceptado, las aplicaciones útiles dejan de parecerse a un simple sistema de alertas.
Los demás canales avisan a una persona.Este avisa a tu código.
Toda la plataforma en la prueba gratuita — todo tipo de comprobación, más de 171 sondas y cada incidente confirmado entregado como un objeto que es tuyo.
Las garantías de entrega, por escrito
Nadie puede escribir un gestor fiable a partir de «te 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 responde primero y haz 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 añade 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.
Tus cabeceras, tal cual
Se envían literalmente, así un token bearer o un secreto compartido funcionan. No hay firma del cuerpo — comprueba la cabecera en tu servidor y mantén 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 la escalada. 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 monitorización
Uptimia comprueba tus sitios web desde más de 171 ubicaciones externas y, cuando una comprobación falla, envía una solicitud HTTP POST con un cuerpo JSON a cualquier URL que registres. 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. Ramifica según ambos campos.
Confirmado antes de que tu 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 alerta →| 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, en la 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é enviáis 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¿Seguís 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 confirmados
Registra un endpoint, asígnalo a los monitores que importan, y cada fallo confirmado llegará como un objeto que tus sistemas pueden archivar y sobre el que pueden actuar.