Envía cada alerta a su canal
Una misma falla que dispara diez veces en cinco minutos no debería avisar diez veces a diez personas. Este endpoint toma una alerta, aplica sus reglas de enrutamiento y una ventana de deduplicación, y la envía exactamente al canal que debe verla, una sola vez.
Ejecútela online
Ejecute esto en nuestros servidores con su cuenta. Las herramientas gratuitas corren en su navegador; esta cobra de su saldo del KIT según el precio de arriba.
Pensada para el espacio entre 'algo se rompió' y 'la persona correcta ya lo sabe'
La mayoría de los sistemas pueden detectar un problema; menos pueden decidir, de forma consistente, quién debe enterarse y por qué canal, sin que un humano escriba esa lógica en cada integración por separado. notify.alert centraliza esa decisión — umbrales de severidad, horarios de guardia, canal preferido según el tipo de alerta — para que su monitoreo, su código de aplicación y sus integraciones de terceros envíen alertas por una sola puerta en vez de que cada uno tenga su propio webhook de Slack a mano.
Cómo funcionan juntos el enrutamiento y la deduplicación
POST /notify/alert recibe un evento con una fuente, una severidad y una clave de deduplicación que usted elige — a menudo una combinación del tipo de alerta y el recurso afectado. Si llega otra alerta con la misma clave dentro de la ventana configurada, se pliega sobre la alerta existente en vez de disparar una segunda notificación; una vez que pasa la ventana o la alerta se reconoce, la siguiente ocurrencia empieza de nuevo. Las reglas de enrutamiento deciden entonces el destino — Slack para advertencias, un canal que llega al teléfono para severidad crítica, correo para eventos informativos — según criterios que define una sola vez.
La fatiga de alertas es un problema viejo y bien documentado
El patrón de equipos que silencian o ignoran alertas porque llegan demasiadas de bajo valor mezcladas con las importantes es anterior por décadas al monitoreo en la nube moderno; es el mismo modo de falla que aparece en salas de control industrial y en equipo hospitalario, y parte de por qué la deduplicación y el enrutamiento por severidad se volvieron práctica estándar en la gestión de incidentes en vez de un lujo. Construimos este endpoint alrededor de esa lección, en lugar de tratar cada alerta como igualmente urgente por defecto.
Dónde se ubica respecto a los otros endpoints de notificación
Piénselo como la capa de decisión que va delante de notify.slack, notify.discord, notify.webhook y notify.digest: su monitoreo o su código de aplicación envía todo aquí, y la configuración de enrutamiento decide cuál de esos canales se dispara para una alerta dada, o si en cambio debe esperar al siguiente resumen. Eso mantiene la lógica de enrutamiento en un solo lugar en vez de duplicada en cada servicio que puede levantar una alerta.
Qué recibe de vuelta para confirmar que funcionó
Recibe la decisión de enrutamiento tomada — qué canal se usó y por qué, además de si la alerta era nueva o se deduplicó contra una existente — mediante un webhook firmado o un enlace firmado válido por 24 horas. Si ninguna regla coincide con una alerta, eso se reporta explícitamente en vez de que la alerta se pierda en silencio, así que los vacíos en su configuración de enrutamiento salen a la luz de inmediato y no durante un incidente real.
Qué puede hacer con ella
Deduplicar chequeos de monitoreo inestables
Un chequeo de salud que alterna entre éxito y fallo dispara alertas cada minuto; la deduplicación las agrupa en un solo incidente activo en vez de avisar repetidamente a la guardia.
Enrutamiento por severidad hacia la guardia
Las alertas críticas de base de datos se enrutan al canal que llega al teléfono de guardia, mientras las advertencias de baja severidad van a un canal de Slack que nadie necesita ver de inmediato.
Centralizar alertas de muchos servicios
Una docena de microservicios levantan alertas a través del mismo endpoint, y una sola configuración de enrutamiento decide los destinos en vez de tener doce integraciones separadas.
Escalamiento según el tipo de alerta
Las alertas relacionadas con seguridad siempre se enrutan al canal de seguridad sin importar la severidad, mientras las alertas de infraestructura siguen las reglas estándar por severidad.
Preguntas frecuentes
¿Cómo funciona la deduplicación en esta api para enrutar alertas?
Envía una clave de deduplicación con cada alerta; las alertas repetidas que comparten esa clave dentro de la ventana configurada se pliegan sobre la alerta existente en vez de generar una notificación nueva.
¿A qué canales puede enrutar notify.alert?
Enruta a cualquiera de los otros endpoints de notificación de su cuenta — Slack, Discord, webhook o resumen diario — según las reglas que configure por severidad, fuente o tipo de alerta.
¿notify.alert es gratis?
No hay capa gratuita: las capas gratis se abusan y ralentizan a todos. El acceso funciona con un saldo prepago de ForHosting KIT: se recarga desde $10.00 (no caduca) y cada solicitud se cobra a su precio publicado, así que una llamada sin saldo devuelve HTTP 402. Sin suscripción, sin tokens ni créditos inventados, y una tarea fallida no se cobra.
¿Cuánto cuesta enrutar una alerta?
Son 0.002 dólares por cada solicitud POST /notify/alert; la decisión de enrutamiento en sí no suma cargos extra más allá del costo propio por notificación del canal que finalmente se dispare.
¿Qué pasa si ninguna regla coincide con una alerta?
La respuesta reporta explícitamente que ninguna regla coincidió, en vez de descartar la alerta en silencio, para que pueda detectar vacíos en su configuración de enrutamiento antes de que importen.
¿Puedo definir distintas ventanas de deduplicación por tipo de alerta?
Sí, las ventanas de deduplicación se configuran por regla, así que un chequeo inestable y una falla crítica poco frecuente pueden usar ventanas distintas según convenga.
¿Una alerta puede notificar a varios canales a la vez?
Sí, una regla de enrutamiento puede repartirse a más de un canal, por ejemplo Slack y un canal que llega al teléfono juntos para severidad crítica.
¿Se conservan los datos de la alerta después de enrutada?
No, los payloads de las alertas y el historial de enrutamiento se eliminan tras el período de retención indicado y nunca se usan para entrenar modelos.
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, y pronto desde nuestra app, el email y Telegram.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/notify/alert \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"input":"…"}'const res = await fetch("https://api.kit.forhosting.com/notify/alert", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"input": "…"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/notify/alert",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"input": "…"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/notify/alert", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"input":"…"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"input":"…"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/notify/alert", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"input": "…"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "notify.alert",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |