Webhooks de alertas

Cada regla de alerta puede hacer POST a una URL de webhook. Pega el webhook de un chat y recibes las alertas en el canal que tu equipo ya lee; pega tu propio endpoint y recibes un payload JSON estructurado con el que puedes hacer lo que quieras.

Payloads según el proveedor

LaunchPulse mira el hostname de tu URL de webhook y adapta el cuerpo de la petición al receptor. No hay nada que configurar: pasa solo.

Google Chat (chat.googleapis.com) y Slack (hooks.slack.com)

{ "text": "🚨 Signup spike — MyApp: account_created = 812 (≥ 500) in 1h" }

Discord (discord.com, discordapp.com)

{ "content": "🚨 Signup spike — MyApp: account_created = 812 (≥ 500) in 1h" }

Todo lo demás: el payload genérico

{
  "type": "alert.fired",
  "project": "MyApp",
  "rule": "Signup spike",
  "kind": "threshold",
  "metric": "events",
  "event": "account_created",
  "window_minutes": 60,
  "op": "gte",
  "threshold": 500,
  "value": 812,
  "at": "2026-08-11T10:00:00.000Z",
  "text": "🚨 Signup spike — MyApp: account_created = 812 (≥ 500) in 1h"
}

Por qué existe esta adaptación

Porque cada proveedor de chat exige algo distinto, y dos de ellos son estrictos al respecto:

• Google Chat rechaza cualquier campo desconocido. Si le mandas el payload estructurado completo, la petición falla directamente.
• Slack exige text.
• Discord exige content.

Mandar un único cuerpo universal implicaría fallar en al menos dos de los tres. Por eso el payload genérico lleva ambas cosas: los campos estructurados y una cadena text legible por humanos, que es exactamente la misma frase que reciben los chats. Si estás escribiendo tu propio receptor y solo quieres reenviar el mensaje a algún lado, lee text e ignora el resto.

Campos del payload genérico

Ramifica según type si quieres tratar las recuperaciones distinto de los disparos, y tolera siempre null en event, op y threshold: una regla de ausencia sobre todos los eventos manda null en los tres.

Ten en cuenta que el texto de la notificación siempre está en inglés, sin importar en qué idioma uses la app. No se sabe quién recibe un webhook, así que no hay contra qué localizar.

Configurar Google Chat

1. Abre el espacio de Google Chat donde quieres las alertas.
2. En el menú del nombre del espacio, ve a Apps e integraciones → Webhooks → Agregar webhook.
3. Ponle un nombre (LaunchPulse) y guarda. Copia la URL: está en chat.googleapis.com.
4. En LaunchPulse, abre la página Alerts de tu proyecto, edita o crea una regla y pega la URL en el campo Webhook URL.
5. Guarda y presiona Enviar prueba. El mensaje debería aparecer en el espacio en un segundo.

Configurar Slack

1. En Slack, crea un incoming webhook para el canal que quieras, ya sea con una app de Slack con Incoming Webhooks habilitado o con la integración Incoming WebHooks.
2. Copia la URL del webhook. Está en hooks.slack.com.
3. Pégala en el campo Webhook URL de la regla y guarda.
4. Presiona Enviar prueba.

Configurar Discord

1. En Discord, entra a Configuración del servidor → Integraciones → Webhooks → Nuevo webhook (o desde el canal, Editar canal → Integraciones).
2. Elige el canal, ponle nombre y usa Copiar URL del webhook. Está en discord.com.
3. Pégala en el campo Webhook URL de la regla y guarda.
4. Presiona Enviar prueba.

Para los tres: si la prueba no llega, revisa la actividad reciente en la página de alertas. Una marca de falló la entrega significa que lo enviamos y el receptor dijo que no.

Por qué te pueden rechazar la URL del webhook

La entrega de un webhook es un servidor haciendo una petición saliente en tu nombre, así que la URL se valida con dureza. Estas reglas existen para impedir que LaunchPulse se use para sondear redes privadas.

Solo https. Las URLs http:// se rechazan al guardar.

El host debe ser accesible públicamente. Entre los hostnames bloqueados están localhost, cualquier cosa bajo .local o .internal, y los hostnames de metadatos de nube. Entre los rangos de direcciones bloqueados:

Están bloqueados en cualquier notación: decimal, hexadecimal, octal, IPv6-mapped. Escribir 127.0.0.1 de otra forma no te deja pasar.

La validación se repite al momento de la entrega. La URL se vuelve a comprobar y se resuelve por DNS cuando la alerta realmente dispara, y la conexión se fija a la dirección que fue validada. Eso anula el DNS rebinding, donde un hostname resuelve a una IP pública durante la comprobación y a una privada un instante después.

Timeout de 10 segundos. Si tu endpoint no respondió en diez segundos, la entrega falla. Confirma rápido y haz tu trabajo de forma asíncrona.

No se siguen redirecciones. Danos la URL final.

Cualquier respuesta que no sea 2xx cuenta como entrega fallida. Queda registrada en la actividad con la marca de falló la entrega. No hay reintentos: recuerda que las alertas son por flanco, así que una entrega fallida en un cambio de estado es un mensaje perdido, no un mensaje demorado.

Probar en local

No se puede. Un túnel o una dirección de LAN serán rechazados por las reglas de arriba, y http://localhost:3000 también.

Usa un endpoint público con https. Un servicio como webhook.site te da una URL en un clic y te muestra exactamente la petición que enviamos: headers, JSON, todo. Es la forma más rápida de ver un payload real antes de escribir una línea de tu receptor. Cuando tu receptor esté desplegado detrás de https público, apunta la regla ahí y presiona Enviar prueba de nuevo.

Qué sigue

• Alertas — tipos de regla, ventanas y cómo se controla la evaluación
• Insights — el gráfico que vas a mirar cuando una alerta te despierte
• Seguridad — cómo trata el resto del sistema tus datos