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

Andá al tab Alta, acá arriba. Elegís el tipo y el formulario muestra solo los campos que ese tipo usa. Si el slug ya existe, lo actualiza y lo reactiva en vez de duplicarlo.

Cargá el Workflow ID aunque sea opcional: es lo que hace que el nombre en la lista linkee al flujo, y es la diferencia entre abrirlo de un clic o buscarlo a mano justo cuando algo se está cayendo.

Antes de darlo de alta, según qué dispara el flujo hay que agregarle:

• Con webhook propio (tipo ping) — 1 nodo Webhook suelto, GET /<cliente>-health, Respond Immediately y Response Data {"ok":true}, sin conectar a nada y 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 el formulario.
• Con schedule (tipo latido) — 1 nodo Execute Sub-workflow al final del camino feliz, así prueba que terminó y no solo que arrancó.
• Panel estático — nada, solo la URL.

Después de guardar aparece en la lista como Unknown y pasa a Online en el próximo tick, a los 5 minutos como mucho. Si queda en Unknown u Offline, la columna Detalle dice por qué.

Para cargar varios servicios de golpe conviene el SQL directo, no el formulario: los insert por tipo están en el repo privado del proyecto.

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, y este panel es la fuente de registro: la columna Token los muestra y los copia. Por eso importa cómo está hecho:

• No viajan en el listado. El listado se refresca solo cada 60 segundos; si los tokens fueran en ese payload quedarían dando vueltas todo el tiempo en memoria del navegador y en el historial de red. Se piden de a uno, recién al clickear el ojo.
• Se ocultan solos a los 2 minutos, y al cerrar sesión no queda ninguno en memoria.
• Detrás del mismo login. Pedir un token exige la misma cuenta @giwa-ia.com validada contra Google; sin eso devuelve 401 sin tocar la base.

Lo que sigue valiendo: ningún panel de cliente puede leer de sla_servicios. Un status page abierto tiene que leer de sla_estado y sla_eventos, nunca de acá.