La Analogía del Paracaídas
Un paracaidista no espera que el paracaídas falle para entrenar a usarlo. Lo abre preventivamente y revisa su empaque cada vez. Lo mismo aplica a los workflows en producción: el error va a pasar (servidor caído, credencial expirada, formato cambiado), tu trabajo es no quedar indefenso cuando pase.
Las 3 causas #1 de fallos en producción
- Infraestructura: el servidor externo está caído (5xx, timeout, DNS). Ocurre ~3% del tiempo en cualquier API seria.
- Credenciales: tokens que expiraron, API keys rotadas por el proveedor, OAuth refrescado. Ocurre cada 30-90 días si no automatizas.
- Cambio de formato: el proveedor actualizó su schema sin avisar (Google, Meta, bancos son famosos por esto). Ocurre 1-2 veces al año.
Regla de oro de GabyMatic: si un flujo corre en producción, debe tener manejo de error. Sin excepción. Sin "después lo pongo".
¿Por qué gestionar errores?
Un sistema automatizado en producción fallará inevitablemente. Un profesional no evita el error, gestiona la consecuencia del error. Esa diferencia separa un script de domingo de un producto que un cliente paga.
Resiliencia · tres estrategias combinables
// 1. Retry (reintentar)
"Reintenta 3 veces con espera exponencial antes de rendirte"
Úsalo para errores transitorios (5xx, timeouts, red inestable).
// 2. Fallback (respuesta alternativa)
"Si la API principal falla, usa un caché o servicio secundario"
Úsalo cuando la disponibilidad > la precisión.
// 3. Alerta a humano
"Notifícame por Telegram/Email/Slack cuando algo falle"
Úsalo siempre. Es tu red de seguridad final.El Error Trigger: tu red de seguridad
El Error Trigger es un tipo especial de trigger que solo se activa cuando otro workflow falla. Es la herramienta principal de n8n para construir alertas y recuperación.
| Paso | Detalle |
|---|---|
| Nombre del workflow | Crea un workflow llamado alertas-de-fallo (uno solo para TODOS tus flujos). |
| Trigger único | Su único trigger es Error Trigger (no agregues otro). |
| Contexto disponible | $json.execution.id, $json.workflow.name, $json.error.message, $json.error.node. |
| Mensaje sugerido | "🚨 {{ $json.workflow.name }} — Error: {{ $json.error.message }} — Ejecución: {{ $json.execution.id }}" |
| Vinculación | En el workflow original, abre Settings → Error Workflow y selecciona alertas-de-fallo. |
| Activación | Activa ambos workflows. Ahora cualquier fallo en cualquier flujo te llega a Telegram. |
Configuración en cada workflow
En el workflow principal abre Settings (icono de engranaje abajo del nombre) → Error Workflow → selecciona el workflow de alertas. Esto vincula el Error Trigger al flujo principal. Sin este paso, el Error Trigger nunca se dispara.
Errores comunes de gestión de errores
Error #1 — no manejar el error (flujo muere silencioso)
Tu webhook recibe un lead pero el nodo de Telegram falla. Sin manejo, n8n marca la ejecución como "Error" pero el cliente que llenó el formulario nunca se entera. Tú tampoco, porque no hay alerta. El lead se pierde y tú lo descubres semanas después. Solución: SIEMPRE configurar Error Workflow.
Error #2 — notificar al cliente equivocado
Las alertas de error caen en el mismo Telegram donde envías mensajes al cliente. Resultado: el cliente ve un "🚨 Fallo en workflow-pagos" y se asusta. Solución: usa un bot de Telegram dedicado para alertas (separado del bot del cliente) o un canal de Slack privado.
Error #3 — ignorar códigos 4xx vs 5xx
Un 400 (Bad Request) es tu culpa (body mal armado, campo faltante). No tiene sentido reintentar, va a fallar igual. Un 500 o 503 es del proveedor, ahí sí reintenta con backoff. Configura retry solo en 5xx y timeouts, nunca en 4xx.
Error #4 — alerta sin contexto útil
"Algo falló" no es una alerta accionable. Una alerta útil incluye: nombre del workflow, nodo que falló, mensaje del error, ID de ejecución (para abrirla en n8n), y datos de entrada (para reproducir). Si tu alerta no dice qué hacer, es ruido.
Práctica guiada: simular un fallo y capturarlo
Objetivo: diseñar un flujo con manejo de error que notifique por Telegram cuando el nodo principal falle.
- Workflow A (
lab-06-principal): Webhook → Telegram. Configura el nodo Telegram con un Chat ID falso (ej.-999999) para forzar el fallo. - Workflow B (
lab-06-alertas): trigger Error Trigger → Telegram (con tu Chat ID real). - En Workflow A: Settings → Error Workflow =
lab-06-alertas. - Activa ambos workflows.
- Desde Postman, envía un POST al webhook de A. Verás: ejecución marcada como error en A, alerta recibida en Telegram desde B.
- Cambia el Chat ID del Workflow A al correcto. Vuelve a enviar. Ahora funciona: la alerta no se dispara.
Error Trigger · campos disponibles en la alerta
// $json del Error Trigger contiene:
{
"execution": {
"id": "exec_abc123",
"url": "https://n8n.gabymatic.com/execution/exec_abc123"
},
"workflow": {
"id": "wf_xyz",
"name": "lab-06-principal"
},
"error": {
"message": "Bad Request: chat not found",
"node": "Telegram"
}
}
// Mensaje útil de Telegram
"🚨 {{ $json.workflow.name }} falló en {{ $json.error.node }}
{{ $json.error.message }}
Revisa: {{ $json.execution.url }}"Checklist del Módulo 06
Desafío de arquitecto
Workflow a prueba de todo (casi)
Tu misión final de fase:
- Toma el lab-05 (Webhook → Telegram con datos dinámicos) y hazle las 3 mejoras.
- Retry automático: en el nodo HTTP Request a Telegram, activa "Retry on Fail" con 3 intentos y espera de 2s, 5s, 10s.
- Error Workflow: vincúlalo al workflow de alertas que ya tienes.
- IF de respaldo: agrega un nodo IF después del HTTP Request que verifique
{{ $json.ok }} === true. Si falla, envía un Email alternativo con el mismo mensaje (fallback de canal). - Simula 3 fallos: Chat ID falso, token falso y URL mal. Verifica que las 3 alertas llegan distintas y accionables.
Bonus: agrega un nodo Postgres que guarde cada fallo en una tabla errores_log con timestamp, workflow, nodo y mensaje. Tu auto-diagnóstico del futuro.