Alertas que puedes auditar

Canales

• Correo — qué ocurrió, desde cuándo, qué regiones de sondeo lo confirmaron y un enlace directo a la comprobación.
• Telegram — a través de un bot que gestiona okokumo, así que la configuración es pulsar Conectar y luego Start en lugar de registrar un bot propio.
• Slack — un incoming webhook que pegas, entregado como bloques con formato, con envío de prueba desde la interfaz.
• Discord — un incoming webhook que creas en tu propio servidor (Canal → Editar canal → Integraciones → Webhooks) y pegas igual. Las alertas llegan como un embed — rojo si cae, verde al recuperarse, gris si está en pausa — con el cambio de estado, la hora, el motivo y el objetivo, y el título enlaza de vuelta a la comprobación. Nada que instalar y ningún bot que invitar.
• Webhook — JSON firmado sobre HTTPS a cualquier endpoint, reintentado con backoff y con payload documentado. Cada entrega lleva una firma HMAC para que quien la recibe pueda verificar que viene de nosotros.

No hay SMS ni llamadas de teléfono. Ambos están en la lista de lo que este producto no hace.

Un canal no recibe nada hasta que se confirma

Añadir un canal son dos pasos, no uno. El correo se valida cuando pulsas el enlace enviado a esa dirección; el webhook, Slack y Discord se validan en el momento en que una entrega de prueba funciona. Hasta entonces el canal existe pero está pendiente, y los canales pendientes no reciben nada.

Es deliberado, y merece entenderse en lugar de sortearse: garantiza que una alerta nunca vaya a un destino que nadie ha confirmado — una dirección con un error tipográfico, un webhook que nunca fue alcanzable, un canal de Slack que se borró. El precio es que una comprobación puede caer sin avisarte si su único canal nunca se confirmó, y justo por eso existe el registro de entregas de más abajo y lo dice.

Enrutado

Los canales pueden asociarse a comprobaciones concretas o dejarse como valor por defecto de la organización que cubre todo. Así la API de cara al cliente puede despertar un teléfono por Telegram mientras una tarea nocturna por lotes escribe en una sala de Slack que nadie mira a las 3 de la mañana.

Una incidencia, una alerta

Una transición a caído envía una vez. Mientras el estado no cambia, nada vuelve a notificar — un servicio caído durante seis horas no produce seis horas de mensajes, porque un canal que da falsas alarmas se silencia, y un canal silenciado es peor que ninguna monitorización. La recuperación envía su propia notificación, así que el silencio nunca hay que interpretarlo.

Por debajo, un fallo tiene que confirmarse desde una segunda región de sondeo de la UE independiente antes de que nada de esto empiece. Cómo funciona eso →

La parte que nadie más te muestra

app.okokumo.com/checks/api

Cada comprobación mantiene un registro de entregas: qué se envió, a qué canal, cuándo — y qué se omitió, con el motivo. Deduplicado porque el estado no había cambiado. Omitido porque el canal seguía pendiente. Fallido porque el endpoint devolvió un 500.

Todos los productos de monitorización afirman que te alertan. Esta es la afirmación que se puede comprobar, y la razón de que el registro sea una función y no una tabla interna.

A través de la API

Las alertas de una comprobación se pueden leer con la API REST versionada usando una clave de organización, junto a comprobaciones, estados y resultados. Documentación →