Tres formas de romperse

Cada una es invisible para las otras dos. Un flujo que dejó de correr no genera errores, y un webhook huérfano responde que todo está bien.

Dar de alta un servicio

Siempre una fila en giwa.sla_servicios. Según qué dispara el flujo, cambia lo que hay que agregarle:

• Con webhook propio — 2 nodos (Webhook GET /x-health + Respond), adentro del mismo workflow. En otro workflow respondería 200 aunque el agente esté muerto.
• Telegram o Meta — nada en el flujo, solo el token en la fila.
• Con schedule — 1 nodo Execute Sub-workflow (Latido) al final del camino feliz, así prueba que terminó y no solo que arrancó.
• Panel estático — nada.

insert into giwa.sla_servicios (servicio, cliente, tipo, url)
values ('mi-servicio', '<cliente>', 'ping', '<url del health>');

insert into giwa.sla_servicios (servicio, cliente, tipo, secreto)
values ('mi-bot', '<cliente>', 'telegram', '<bot token>');

insert into giwa.sla_servicios (servicio, cliente, tipo, url, secreto)
values ('mi-whatsapp', '<cliente>', 'meta',
        'https://graph.facebook.com/v23.0/<WABA_ID>/subscribed_apps',
        '<access token>');

insert into giwa.sla_servicios
  (servicio, cliente, tipo, intervalo_min, tolerancia_min)
values ('mi-schedule', '<cliente>', 'latido', 60, 20);

Operarlo

update giwa.sla_servicios set activo = false
where servicio = 'mi-servicio';

Las alertas están calibradas para seguir siendo legibles con decenas de servicios: avisan solo cuando cambia el estado, exigen dos fallos seguidos antes de declarar una caída, mandan un mensaje con todo lo caído en vez de uno por servicio, recuerdan cada hora mientras siga roto y avisan cuando se recupera.

Una ejecución cada 5 minutos cubre todos los servicios: 288 por día, contra las más de 10.000 que serían chequeos individuales por flujo.

Ojo con los tokens

Los tokens de bot viven en la columna secreto. Esa tabla no puede quedar expuesta por el webhook de ningún panel de cliente: este panel lee de sla_estado y sla_eventos, nunca de sla_servicios.secreto.