Si se rompe la automatización, ¿quién la arregla y en cuánto tiempo?

Si se rompe, la arregla quien esté nombrado por contrato, en el plazo que ese contrato fije: para un flujo crítico, detección en menos de 15 minutos y restablecimiento dentro del mismo día hábil. Si no hay nombre ni plazo escritos, la respuesta real es que no la arregla nadie hasta que se queja un cliente, y eso tarda días. Toda automatización que depende de una API de terceros —WhatsApp, Mercado Libre, Google Calendar, un proveedor de IA— se rompe alguna vez, y casi nunca por un error del código: se rompe porque algo cambió afuera. Lo que separa un incidente de 40 minutos de uno de tres días no es la calidad del desarrollo, son tres definiciones que se toman antes de firmar: quién recibe la alerta, en cuánto tiempo se detecta la falla y cuál es el plazo comprometido para restablecer. Si tu contrato no dice esas tres cosas, no tenés soporte: tenés un teléfono.

Casi nada se rompe solo: cambia algo afuera y tu flujo se entera último

Estos son los modos de falla que aparecen en operación real, con nombre y apellido:

• Se apaga la versión de la API que estabas usando. Meta versiona la Graph API y cada versión tiene una vida útil de alrededor de dos años; la fecha de apagado se publica con meses de anticipación en el changelog para desarrolladores. El día que llega, las llamadas a esa versión dejan de responder. Es la falla más previsible que existe y también una de las más comunes, porque el aviso le llega a quien administra la app de Meta, no al dueño del negocio.
• Vence un token que nadie sabía que vencía. El clásico: alguien generó en el panel de Meta el token temporal de 24 horas para probar y ese token quedó pegado en producción. La variante lenta es peor: el token de usuario del sistema no expira por tiempo, pero está atado a una cuenta. Si esa cuenta pierde acceso al Business Manager, el token muere con ella.
• Se va la persona que autorizó las cuentas. La empleada de administración conectó el Google Calendar y la casilla de correo con su usuario. Renuncia, se le da de baja la cuenta corporativa el viernes, y el lunes el bot no puede leer la agenda ni mandar confirmaciones. Nadie relaciona una cosa con la otra durante días, porque en el ticket de baja no dice que ese usuario sostenía tres integraciones.
• Se retira el modelo de IA. El nombre del modelo está escrito en el nodo. El día del apagado, cada mensaje devuelve error de modelo inexistente. Los proveedores avisan con meses de anticipación, pero el aviso llega por mail a la cuenta que creó la API key, que en muchos casos es la del proveedor y no la tuya. Si esa relación se enfrió, el aviso lo lee un buzón que nadie abre.
• Cambia el HTML de un sistema que no tiene API. Portal de un mayorista, panel de una obra social, extranet de una aseguradora: cuando no hay API, el flujo lee la pantalla. Un rediseño, un campo que pasa a cargarse por JavaScript o un captcha nuevo, y el dato deja de encontrarse. No hay aviso previo ni a quién reclamarle. Si algo de tu operación depende de leer pantallas ajenas, asumí al menos una rotura por año y presupuestala.
• Cambia tu propio volumen. Nadie tocó nada, pero pasaste de 400 a 1.400 conversaciones por mes y la API empieza a devolver 429 (demasiadas solicitudes) en el pico de las 11. Es la falla más difícil de diagnosticar porque es intermitente: a las 16 funciona perfecto y el reclamo del cliente suena a exageración.

Monitoreamos 24/7 no significa nada: pedí estas cuatro piezas

Monitoreo de verdad son cuatro cosas concretas y verificables. Si falta alguna, hay un modo de falla de los de arriba que nadie va a ver hasta que lo vea un cliente.

Una alerta que se dispare por ausencia, no sólo por error. Si el flujo de recordatorios manda 40 mensajes cada mañana a las 9, la alerta útil no es "el nodo falló", es "a las 9:15 no se registró ningún envío". Se implementa con un monitor de tipo latido: el flujo avisa que corrió y un servicio externo (healthchecks.io, Better Stack, o un flujo testigo separado) grita si el aviso no llega. Sin esto, la ejecución que termina en verde sin haber hecho nada no la detecta nadie, y esa es la falla que más caro sale.

Reintentos con espera creciente, y sólo para los errores que corresponde. Un 429 o un 503 son temporales: reintentar a los 5 segundos, a los 25 y al minuto resuelve la mayoría sin que nadie se entere. Un 401 (credencial inválida) o un 400 (dato mal formado) no se arreglan reintentando; ahí el reintento sólo multiplica el error y en algunas plataformas acelera el bloqueo. En n8n esto son dos opciones por nodo, Retry On Fail y Wait Between Tries, más un ramal que separe el tipo de error. Preguntá si están configuradas: en n8n vienen apagadas por defecto, así que si nadie las tocó nodo por nodo, no lo están.

Idempotencia, para que reintentar no duplique. Es la pieza que más se saltea y la que genera los incidentes más incómodos con clientes. Si el reintento vuelve a ejecutar la acción completa, la misma persona recibe dos WhatsApp, se emite dos veces la misma factura o se descuenta dos veces el stock. La solución es barata: antes de ejecutar, guardar el identificador de origen del evento —el id del mensaje, el número de pedido, el id del turno— en una tabla con restricción de unicidad, y si ya existe, no ejecutar. La pregunta para tu proveedor es literal: si el mismo webhook llega dos veces, y llega, porque las plataformas reenvían cuando no reciben respuesta a tiempo, ¿qué pasa?

Una cola de errores que alguien mira. Lo que falló después de todos los reintentos no puede morir en un log. Va a una tabla, una planilla o un canal, con los datos suficientes para reprocesarlo cuando se arregle la causa; n8n tiene Error Workflow exactamente para eso. La diferencia práctica: cuando el token se reautoriza el martes, los 63 mensajes del lunes se reenvían en dos minutos en lugar de perderse para siempre.

El mismo incidente, con y sin esas piezas

Escenario: e-commerce con 900 SKUs que vende en Tiendanube y Mercado Libre, con un flujo de n8n que sincroniza stock cada 10 minutos. Un viernes a las 19:40 se invalida la credencial de Mercado Libre. Ticket promedio USD 62. Los valores son típicos para un e-commerce chico de la región, no resultados auditados de una empresa concreta.

Sin monitoreo. La sincronización deja de correr y las publicaciones de Mercado Libre quedan mostrando el stock del viernes a la tarde. Se detecta el lunes 9:30, cuando entra el tercer reclamo: 62 horas de falla. En el medio se vendieron 11 unidades que ya no existían, que hay que cancelar desde la cuenta del vendedor. Costo directo: USD 682 en ventas caídas, más unas 3 horas de la persona de atención gestionando cancelaciones y reembolsos, más el golpe a la reputación de vendedor, que se calcula sobre las ventas recientes y tarda meses en recuperarse. El arreglo técnico son 40 minutos de reautorización. El arreglo nunca es lo caro.

Con las cuatro piezas. Dos ciclos fallidos consecutivos (20 minutos) disparan la alerta. El flujo entra en modo seguro: en vez de dejar publicado un stock que ya no puede validar, congela las publicaciones o las lleva a cero. A las 20:15 alguien reautoriza desde el celular; si no hay guardia, se reautoriza el lunes a las 9 y en el medio no se vendió nada que no existiera. La cola de errores reprocesa los cambios de stock pendientes. Costo: 40 minutos de trabajo y algunas ventas no realizadas, que son mucho más baratas que las ventas canceladas.

La decisión de diseño que más plata salva es la que casi nunca se cotiza: definir qué hace el sistema cuando no puede cumplir. Un bot que no logra consultar el precio tiene que decir "te paso con una persona", no inventar un número ni quedarse mudo.

Las seis preguntas que separan soporte real de un número de teléfono

1. ¿Qué alerta se dispara, a quién le llega y en cuánto tiempo? Una buena respuesta suena así: si a las 9:15 el lote no salió, entra un aviso al canal de soporte y, si a los 30 minutos sigue sin resolverse, un mail a vos.
2. ¿Cuál es el tiempo de respuesta y cuál el de restablecimiento? Son cosas distintas y conviene pedirlas por severidad: bot caído, falla parcial, detalle cosmético. Un acuse de recibo en 4 horas hábiles no es una solución en 4 horas hábiles.
3. ¿Qué pasa un sábado a las 22? La respuesta honesta y aceptable es "no hay guardia, se atiende el lunes a las 9, salvo que contrates guardia aparte". La respuesta sospechosa es "siempre hay alguien".
4. ¿Los cambios de terceros entran en el abono o se cotizan? Cuando Meta apague la versión de la API o el proveedor retire el modelo, ¿quién paga esa migración? Es la cláusula que más plata mueve y la que casi nadie pregunta.
5. ¿Quién más, además de la persona que lo armó, puede entrar mañana? Si la respuesta es un nombre propio, tu automatización tiene un único punto de falla y es humano. Lo que lo resuelve es documentación y credenciales en un gestor compartido, no confianza.
6. ¿Cuál es el plan manual mientras está caído? El número sigue recibiendo mensajes. Que alguien pueda contestar a mano desde la bandeja compartida —Chatwoot o la que uses— convierte una pérdida en una molestia.

Descalifican: "eso no se rompe", "está en la nube", y cualquier SLA que hable sólo de uptime del servidor. Que el VPS esté al 99,9% no dice nada sobre si tus mensajes salieron: el servidor puede estar impecable con el token vencido hace una semana.

El simulacro: pedí que rompan el flujo delante tuyo, en el mes 1

El simulacro se hace en 20 minutos. Se revoca a propósito una credencial en un ambiente de prueba, o se apaga el nodo de envío, y se cronometran tres cosas: cuánto tarda en llegar la alerta, a quién le llega y si los eventos fallidos quedaron en algún lado para reprocesar. Si a los 30 minutos no llegó nada, el monitoreo no existe, diga lo que diga el contrato. Es el mismo gesto que apretar el botón de prueba del detector de humo: el aparato colgado en el techo no prueba nada, el pitido sí. Pedirlo en el mes 1 sale gratis; descubrirlo en el mes 8 cuesta el incidente completo.

Cuándo esto no vale la plata

No todo flujo necesita monitoreo pago, y venderlo igual sería cobrarte por ruido:

• Si el flujo es interno y tolera un día. Consolidar el reporte mensual de ventas en Looker Studio: si falla el día 1, corre el día 2 y no pasó nada. Alertar eso entrena al equipo a ignorar alertas, que es peor que no tenerlas.
• Si corre dos veces al año. Un cierre de ejercicio o una carga de temporada se cubre mejor con una revisión previa a cada corrida que con 12 meses de monitoreo.
• Si nadie de afuera se entera antes que vos. Ésa es la regla práctica: monitoreá lo que, si falla, lo nota primero un cliente, un paciente o un comprador.
• Si ya tenés equipo de sistemas con guardia. Pagar una segunda guardia es pagar dos veces. Lo que sí conviene comprar es el conocimiento del stack y la documentación, no la disponibilidad.

Qué miramos primero cuando nos llaman con un flujo ya roto

Primero, qué credenciales siguen vivas y a nombre de quién: un token atado a alguien que ya no trabaja ahí se arregla distinto que uno vencido. Después, qué versión de cada API tiene escrita el flujo y si esa versión ya tiene fecha de apagado publicada. Con esas dos respuestas se sabe si lo que tenés es un problema de 40 minutos o una reconstrucción.

Esa revisión es la auditoría gratuita de 15 minutos, y en varios casos termina con un "esto no hace falta monitorearlo: reautorizá el token, documentá quién es el dueño de cada cuenta y seguí". Si querés hacerla sobre tu caso, escribinos a info@striqtech.com o agendá desde striqtech.com.