Guía · Automatización y agentes
Errores y reintentos en automatizaciones con n8n o Make
Cómo manejar fallos en tus flujos automáticos: reintentos, avisos, registros, duplicados y qué hacer cuando una API externa no responde.
Toda automatización falla alguna vez: una API no responde, un dato llega vacío o se supera un límite. Lo importante es que el fallo no pase desapercibido ni duplique acciones. Un flujo robusto reintenta lo que merece reintento, avisa lo que no puede resolver y deja un registro revisable.
Tipos
Tipos de error y respuesta
| Error | Respuesta adecuada |
|---|---|
| Fallo temporal de red o servicio | Reintentar con esperas crecientes |
| Límite de uso alcanzado | Esperar y reintentar más tarde |
| Dato faltante o con formato incorrecto | No reintentar; avisar y revisar |
| Credencial vencida | Avisar al responsable |
| Respuesta inesperada de la API | Registrar y detener el flujo |
Prácticas
Prácticas que evitan problemas
- Valida los datos antes de usarlos y define valores por defecto sensatos.
- Usa un identificador único por operación para no repetirla si se reintenta.
- Limita el número de reintentos.
- Configura una ruta de error que notifique a una persona.
- Guarda en una hoja o base de datos cada ejecución fallida con su causa.
- Evita enviar mensajes a clientes dentro de un bucle sin control.
Duplicados
El problema de los duplicados
Un reintento mal diseñado puede enviar dos veces el mismo mensaje o crear dos veces el mismo contacto. La solución se llama idempotencia: antes de actuar, el flujo comprueba si esa operación ya se hizo, por ejemplo buscando el identificador en el CRM. Esto es crítico en cobros, recordatorios y mensajes por WhatsApp, como se advierte en errores que causan bloqueos.
Monitoreo
Monitoreo mínimo
- Revisa el historial de ejecuciones con regularidad.
- Activa alertas por correo o chat para fallos repetidos.
- Haz pruebas periódicas con datos ficticios.
- Anota los cambios de las APIs que usas.
- Ten un procedimiento para pausar todo el flujo.
El diseño previo ayuda a prevenir fallos: diseñar el flujo antes de montarlo.
Una práctica muy útil es separar el aviso de error de la corrección. Que el flujo notifique no significa que alguien lo atienda; define quién recibe el aviso, en qué canal y en cuánto tiempo debe responder. Para flujos que tocan clientes, añade un mecanismo de pausa: un interruptor que detenga las salidas sin borrar el flujo. Y registra cada ejecución con suficiente contexto para entender qué pasó, sin guardar datos personales innecesarios. Con estos elementos, un fallo deja de ser un susto y se convierte en una tarea más del mantenimiento.
Lista de comprobación final:
- Ruta de error con aviso a una persona.
- Reintentos limitados y con espera creciente.
- Interruptor para pausar el flujo.
Resumen
En resumen
- Prácticas que evitan problemas: Valida los datos antes de usarlos y define valores por defecto sensatos.; Usa un identificador único por operación para no repetirla si se reintenta.
- El problema de los duplicados: Un reintento mal diseñado puede enviar dos veces el mismo mensaje o crear dos veces el mismo contacto.
- Monitoreo mínimo: Revisa el historial de ejecuciones con regularidad.; Activa alertas por correo o chat para fallos repetidos.
Preguntas frecuentes
Lo que suelen preguntar sobre errores y reintentos en automatizaciones
¿Cuántos reintentos son adecuados?
Depende del caso; unos pocos con esperas crecientes suelen bastar. Un reintento infinito puede agravar el problema.
¿Debo guardar los datos fallidos?
Sí, pero con cuidado: si incluyen datos personales, aplica las mismas medidas de seguridad y retención que al resto.
¿Debo probar los errores a propósito?
Sí. Simula datos faltantes y servicios caídos en un entorno de prueba para ver cómo reacciona el flujo.