Módulo 8: Proyecto — Hub de Integraciones
Manejo de Errores y Robustez
Descripción de la cápsula
El hub funciona... cuando todo va bien. Esta cápsula trata lo que pasa cuando no.
Un hub conecta varias herramientas externas, y cada una de esas herramientas falla a veces — no por tu culpa: HubSpot tiene un rate limit a media tarde, Slack está caído un minuto, una credencial de Google caducó, internet parpadeó. En un workflow simple, un fallo así es una molestia. En un hub, es un problema mayor: un fallo a mitad de la distribución te deja el sistema a medias — el lead se registró en el CRM pero la hoja se quedó sin la fila, o el equipo recibió el aviso en Slack pero el cliente nunca recibió su correo.
Esta cápsula te enseña a hacer el hub robusto: a aceptar que las herramientas fallan, a evitar que un fallo de una arrastre a las demás, y a asegurarte de que cuando algo falla, alguien se entera. No es opinión — es la diferencia entre un hub que es un experimento bonito y uno en el que un negocio puede confiar.
Lo que vas a aprender
Al terminar esta cápsula serás capaz de:
- ✅ Entender el problema del fallo parcial en un sistema multi-herramienta
- ✅ Aislar fallos — que el fallo de un destino no arrastre a los demás
- ✅ Usar reintentos para fallos temporales
- ✅ Construir una vía de notificación de errores — que un fallo no pase desapercibido
- ✅ Decidir qué pasos del hub son críticos y cuáles tolerables
- ✅ Reconocer los límites de lo que se cubre aquí (y qué espera en G10)
El problema: el fallo parcial
En un workflow lineal simple, si un nodo falla, el workflow se detiene. Molesto, pero claro — sabes que no terminó.
En un hub, el escenario es más sutil y más peligroso:
El núcleo procesó el lead bien. La distribución empieza: HubSpot ✅, Sheets ✅, Slack ✅... y Gmail falla. ¿Qué tienes ahora? Un lead que está en el CRM, en la hoja, anunciado al equipo — pero el cliente nunca recibió su confirmación. Y si la distribución estaba en secuencia y Gmail era el tercero, quizás Slack tampoco se ejecutó.
Eso es un fallo parcial: el sistema no está ni "bien" ni "fallido" — está a medias. Y lo peor: si nadie revisa los logs, nadie se entera. El cliente simplemente no recibió respuesta, y tú no lo sabes.
El fallo parcial es el problema de robustez de un hub. Las tres defensas de esta cápsula lo atacan: aislar, reintentar, notificar.
Defensa 1: aislar los fallos
El primer principio: el fallo de un destino no debe arrastrar a los demás.
Recuerda la cápsula 05 — la distribución en secuencia tenía esa debilidad: si HubSpot falla, Sheets/Slack/Gmail ni se ejecutan. La solución es aislar cada destino para que sea independiente.
Cómo aislar
n8n permite configurar, por nodo, qué pasa cuando falla. La opción clave es "Continue On Fail" (continuar aunque falle): si la activas en un nodo, cuando ese nodo falla, el workflow no se detiene — sigue, marcando ese item como fallido.
Con cada destino de la distribución configurado así:
- HubSpot falla → Sheets, Slack y Gmail igual se ejecutan
- El lead no se pierde por completo — llega a las herramientas que sí respondieron
El cambio de mentalidad: en lugar de "todo o nada", el hub pasa a "lo más posible, y registro lo que no se pudo". Un fallo de Gmail ya no significa "el hub falló" — significa "el hub hizo 3 de 4, y el cuarto quedó pendiente".
Defensa 2: reintentar los fallos temporales
Muchos fallos de herramientas externas son temporales: un rate limit que se libera en segundos, un parpadeo de red, una API que tarda de más una vez. Para esos, la defensa correcta no es "rendirse" — es reintentar.
n8n permite configurar, por nodo, reintentos automáticos (Retry On Fail): si el nodo falla, n8n espera un momento y lo intenta de nuevo, un número de veces que tú defines.
Cuándo el reintento ayuda y cuándo no:
- Ayuda con fallos temporales: rate limits, timeouts, parpadeos de red. Reintentar a los pocos segundos suele funcionar.
- No ayuda con fallos permanentes: una credencial caducada, un scope que falta, un dato inválido. Reintentar 1.000 veces no arregla una credencial vencida — solo retrasa lo inevitable.
Por eso el reintento es la primera línea, no la única: configura unos pocos reintentos para superar los baches temporales, pero combínalo con la notificación (defensa 3) para los fallos que el reintento no resuelve.
Has visto este principio en cada módulo de troubleshooting de la guía (Sheets, Slack, Airtable, HubSpot todos lo mencionaron). Aquí se vuelve parte de la arquitectura del hub.
Defensa 3: notificar los errores
La defensa más importante, y la que más se olvida:
Un fallo que nadie ve es peor que un fallo ruidoso. Si Gmail falla silenciosamente y el lead no recibe confirmación, y nadie se entera — el negocio pierde un cliente sin saber por qué. Un hub robusto no es uno que nunca falla; es uno que, cuando falla, te lo dice.
La construcción: una vía de notificación de errores. Cuando un destino falla (después de agotar los reintentos), en lugar de quedar en silencio, el hub manda un aviso a un lugar donde alguien lo verá.
Cómo construirla
Con "Continue On Fail" activado, un nodo que falló sigue en el flujo marcado como fallido. Después de cada destino crítico, puedes:
- Un IF que detecta si ese destino falló
- Si falló → un nodo que avisa: un mensaje a un canal de Slack
#errores-hub, o un correo al administrador
El aviso debe decir lo esencial: qué lead (email, nombre), qué destino falló (Gmail), y cuándo. Con eso, una persona puede arreglarlo a mano — reenviar el correo, revisar la credencial.
El patrón completo: aislar (Continue On Fail) para que el hub no se detenga + reintentar para superar los baches temporales + notificar lo que aun así falló. Las tres juntas convierten "fallo parcial silencioso" en "el hub hizo lo que pudo y avisó del resto".
n8n también tiene un mecanismo de Error Workflow — un workflow especial que se dispara automáticamente cuando otro falla. Es una forma elegante de centralizar la notificación. Tenlo en el radar; su configuración fina es territorio de G10.
Decidir: qué es crítico y qué es tolerable
No todos los destinos del hub son igual de importantes. Parte de la robustez es decidir el nivel de cada uno:
| Destino | ¿Qué tan crítico? | Si falla... |
|---|---|---|
| HubSpot (CRM) | Crítico — es el registro maestro del lead | Notificar fuerte; quizás vale reintentar más |
| Sheets (hoja) | Importante, pero es respaldo del CRM | Notificar; recuperable a mano |
| Slack (aviso) | Tolerable — es una conveniencia | Notificar suave; el lead no se pierde por esto |
| Gmail (confirmación al cliente) | Crítico — afecta al cliente directamente | Notificar fuerte; el cliente espera respuesta |
No hay una respuesta universal — depende del negocio. Pero el ejercicio de clasificar cada destino te obliga a pensar dónde poner más esfuerzo de robustez. Gastar energía haciendo "ultra-robusto" el aviso de Slack mientras dejas frágil el correo al cliente es invertir al revés.
Los límites de esta cápsula
Honestidad sobre el alcance:
Esta cápsula te da la robustez fundamental — aislar, reintentar, notificar — que es suficiente para un hub real de PyME y que se construye con lo que ya sabes. Pero el manejo de errores tiene más profundidad: transacciones (deshacer lo que sí se hizo si algo falla), colas de reintento persistentes, monitoreo con dashboards, alertas escaladas. Todo eso es el tema de G10 (Production and Maintenance) del path.
No necesitas G10 para tener un hub en el que confiar. Lo necesitas para operar decenas de workflows críticos a escala. Por ahora: aislar + reintentar + notificar te lleva muy lejos.
Trampas comunes
Trampa 1: Asumir que las herramientas nunca fallan
Qué pasa: Construyes el hub "feliz" y lo das por terminado. La primera vez que HubSpot tiene un rate limit, el hub deja leads a medias en silencio.
Cómo evitar: Un hub no está terminado hasta que es robusto. Las herramientas externas fallan — asúmelo desde el diseño.
Trampa 2: Reintentar fallos permanentes
Qué pasa: Configuras 10 reintentos para todo. Una credencial caducada se reintenta 10 veces, tarda, y al final falla igual.
Cómo evitar: Reintentos para fallos temporales (pocos, rápidos). Para los permanentes, lo que sirve es la notificación, no más reintentos.
Trampa 3: Aislar pero no notificar
Qué pasa: Activas "Continue On Fail" en todo. El hub ya no se detiene... pero ahora los fallos pasan completamente desapercibidos.
Cómo evitar: Aislar sin notificar es peor que no aislar. Las dos van juntas: el hub continúa y avisa de lo que no se pudo.
Trampa 4: Tratar todos los destinos como igual de críticos
Qué pasa: Inviertes el mismo esfuerzo de robustez en el aviso de Slack que en el correo al cliente.
Cómo evitar: Clasifica cada destino (crítico / importante / tolerable) y pon el esfuerzo donde el negocio lo necesita.
Trampa 5: Querer la robustez "perfecta" antes de tener algo
Qué pasa: Te paralizas intentando manejar todos los modos de fallo imaginables antes de que el hub funcione.
Cómo evitar: Aislar + reintentar + notificar es suficiente para empezar. La robustez avanzada es G10 — no la necesitas para tener un hub confiable hoy.
Ejercicio: haz el hub robusto
Objetivo: convertir el hub "feliz" de la cápsula 05 en uno que tolera fallos y avisa.
Tu tarea
- Aislar: activa "Continue On Fail" en los cuatro nodos de distribución. Verifica el concepto: si fuerzas un fallo en uno (ej. una credencial mala a propósito), los otros tres igual se ejecutan.
- Reintentar: configura reintentos (Retry On Fail) en los destinos que tocan APIs con rate limits — HubSpot y Sheets son buenos candidatos. Pocos reintentos, no muchos.
- Notificar: después de los destinos críticos (HubSpot, Gmail), agrega un IF que detecte si falló → si falló, un Slack (Send) a un canal
#errores-hubcon qué lead y qué destino falló. - Clasificar: escribe (en papel) tu tabla de criticidad — para tu hub, ¿qué destino es crítico, importante, tolerable? Justifica.
- La prueba del fallo: rompe una credencial a propósito, dispara un lead, y verifica: el hub no se detuvo, los otros destinos funcionaron, y te llegó la notificación del fallo.
Ver pistas
- "Continue On Fail" y "Retry On Fail" están en la configuración (Settings) de cada nodo.
- En el 3, para detectar si un nodo falló: con Continue On Fail, el item que falló trae información del error — un IF puede revisarlo. Mira el output de un nodo que falló para ver cómo.
- El paso 5 es la prueba que importa: un hub robusto, ante un fallo, hace lo posible y avisa. Si tu hub pasa esa prueba, está listo.
Resumen y siguiente paso
- Un hub conecta herramientas externas que fallan a veces — y el problema propio del hub es el fallo parcial: el sistema a medias, en silencio
- Tres defensas: aislar (Continue On Fail — un fallo no arrastra a los demás), reintentar (Retry On Fail — supera baches temporales), notificar (un fallo que nadie ve es el peor)
- Reintentar sirve para fallos temporales (rate limits, red); no para permanentes (credencial caducada) — para esos, la notificación
- Aislar sin notificar es peor que no aislar — las dos van juntas
- Clasifica los destinos por criticidad (crítico / importante / tolerable) — pon el esfuerzo de robustez donde el negocio lo necesita
- Esta cápsula da la robustez fundamental y suficiente para un hub de PyME; la avanzada (transacciones, colas, monitoreo) es G10
- 5 trampas: asumir que nada falla, reintentar fallos permanentes, aislar sin notificar, tratar todo como crítico, buscar la robustez perfecta antes de tener algo
Antes de avanzar deberías poder:
- Explicar el problema del fallo parcial
- Aislar, reintentar y notificar en el hub
- Clasificar los destinos por criticidad
Lo que sigue (cápsula 07):
El hub funciona y es robusto. La cápsula 07 cubre lo último que separa un proyecto de un sistema vivo: cómo probarlo de verdad y cómo mantenerlo para que siga funcionando dentro de seis meses, cuando las herramientas cambien y el negocio crezca.
Recursos adicionales
- n8n: error handling - Continue On Fail, Retry On Fail y Error Workflows.
- n8n: Error Workflow - Centralizar la notificación de errores.
- Anticipa G10 (Production and Maintenance) del path — la robustez avanzada se cubre ahí.
Creado: Mayo 14, 2026 Versión: 1.0