Ilustrativo: el éxito sigue a la derecha; el error va a la rama de error, que envía una alerta y registra el log.
🚨 Manejo de errores
En producción, todo falla tarde o temprano. Quien maneja errores recibe una notificación; quien no lo atiende se entera por el cliente molesto. Usa un error workflow global, la rama de error del nodo, o continue on fail.
// disparado automaticamente quando QUALQUER fluxo falha Workflow: ={{ $json.workflow.name }} Node: ={{ $json.execution.lastNodeExecuted }} Erro: ={{ $json.execution.error.message }} // → manda esse resumo pro Slack
✓ Flujo que maneja errores
- ✓El Error workflow global avisa de cada fallo.
- ✓continue on fail en un nodo no crítico.
- ✓La rama de error registra el elemento problemático.
✗ Flujo que muere en silencio
- ✗Sin flujo de errores, las fallas pasan inadvertidas.
- ✗Un elemento defectuoso interrumpe todo el lote.
- ✗Nadie recibe una notificación; el cliente se entera antes.
⏱️ Reintentos y timeouts
Muchos fallos son transitoria — API inestable, timeout de red. Un retry con backoff transforma «dio error» en «se resolvió solo en el 2.º intento». Pero define un timeout: esperar indefinidamente bloquea el flujo.
Retry On Fail: true Max Tries: 3 Wait Between Tries: 2000 ms // idealmente crescente (backoff) Timeout: 30000 ms // não espere para sempre
📊 Reintentar con criterio
- Backoff - espera un poco más con cada intento (2s, 4s, 8s) para no martillar la API.
- Solo lo transitorio - Los errores 5xx y los timeouts permiten reintentos; 400/401 no (fallarán igual).
- Límite de intentos - 3 a 5; después, pasa a la rama de error y alerta.
🧬 Idempotencia y cómo evitar duplicados
Reintentos y webhooks vuelven a entregar. Sin idempotencia, cada reenvío se convierte en un duplicado: dos registros, dos correos, el mismo cobro 3x. Idempotente = ejecutar la misma entrada dos veces tiene el mismo efecto que ejecutarla una vez.
// chave idempotente derivada do evento chave = ={{ $json.pedido_id + '-' + $json.tipo_evento }} // UPSERT: se a chave já existe, atualiza; senão, cria // → reenvio do mesmo evento não duplica
Define una clave de idempotencia
Un identificador estable del evento (p. ej., pedido_id) que no cambia entre reenvíos.
Comprueba antes de actuar
Haz un SELECT por la clave antes de insertar, o usa UPSERT, que ya lo resuelve en la base de datos.
Eliminar duplicados antes de notificar
Marca "ya enviado" para que un retry no vuelva a enviar el mismo correo.
📡 Observabilidad: registros y alertas
No arreglas lo que no ves. Logs estructurados registran lo que hizo cada ejecución; alertas los proactivos avisan cuando algo falla. La diferencia entre 5 minutos y 5 horas de pérdidas.
POST ={{ $env.SLACK_ALERT_WEBHOOK }}
{ "text": "🚨 Falha no fluxo *={{ $json.workflow.name }}*\n
Node: ={{ $json.execution.lastNodeExecuted }}\n
Erro: ={{ $json.execution.error.message }}" }
Qué se ejecutó y cuándo
Slack / correo electrónico ante un fallo
Tasa de éxito
Execution history
💡 Consejo práctico
Alerta cuando falla, no cuando todo sale bien; de lo contrario, se convierte en ruido y dejas de leerlo. Y nunca registres la clave de API: enmascara los secretos antes de guardar cualquier línea.
🧪 Pruebas y entorno de homologación
Probar directamente en producción interrumpe el servicio del cliente en vivo. Un entorno de validación (staging) con datos de prueba es tu red de seguridad: valida el cambio allí antes de tocar lo que está en producción.
✓ Con homologación
- ✓Credenciales y datos de prueba separados (ENVIRONMENT=staging).
- ✓Prueba de humo después de cada cambio: ejecuta 1 caso y comprueba.
- ✓Pin data con casos límite (campo nulo, valor enorme).
✗ Probando en producción
- ✗Enviar un correo de prueba a clientes reales.
- ✗Editar el flujo activo sin una copia de seguridad.
- ✗Descubrir el error solo cuando llega el volumen real.
📊 Qué probar antes de promover
- Camino feliz - una entrada normal produce la acción esperada.
- Casos de borde - campo faltante, lista vacía, valor inesperado.
- Falla simulada - interrumpe la API a propósito y observa cómo actúa la rama de error.
✅ Lista de verificación de producción
La lista de verificación transforma «creo que está listo» en «está listo», y es lo que le muestras al cliente como garantía. Antes de activarla de verdad, revisa cada elemento.
🚀 Lista de verificación para la puesta en marcha
💡 Consejo práctico
Ten siempre un plan de rollback: cómo apagar la automatización y volver al proceso manual en 1 clic si algo sale muy mal. Eso te da confianza a ti (y al cliente) para activar el flujo.
📌 Resumen del módulo
Próxima Ruta de aprendizaje:
Ruta 5 · Comercialización - empaquetar, fijar el precio y vender tu automatización como servicio.