Un workflow de n8n que funciona en la demo no está listo para producción. En producción hay APIs que devuelven 500, tokens que caducan, límites de velocidad, datos incompletos y ejecuciones que se solapan. La diferencia entre una automatización útil y una fuente de incidentes está en cómo se manejan esos casos.
Esta es la checklist que usamos antes de activar un flujo que toca datos de negocio.
El camino feliz no es producción
La primera versión de un flujo suele probarse con un registro perfecto: todos los campos completos, la API responde 200 y nadie más está usando el sistema. En producción, el mismo flujo recibe un email sin dominio, un pedido con un importe en otra moneda o una respuesta que tarda treinta segundos.
Antes de activar, conviene preguntarse:
- ¿Qué pasa si la API externa falla?
- ¿Qué pasa si el flujo se ejecuta dos veces con el mismo dato?
- ¿Qué pasa si el volumen se multiplica por diez?
- ¿Cómo me entero de que algo se rompió?
Si no hay respuesta para las cuatro, el flujo todavía es un prototipo.
Idempotencia: la propiedad que evita duplicados
Un flujo es idempotente cuando ejecutarlo dos veces con la misma entrada produce el mismo resultado que ejecutarlo una vez. Es la defensa más importante contra los reintentos y las ejecuciones duplicadas.
En la práctica:
- Usa una clave única por evento (ID del pedido, email + fecha, ID del mensaje).
- Consulta si esa clave ya fue procesada antes de crear un registro.
- Guarda el resultado de la operación, no solo el hecho de haberla intentado.
- Si el sistema externo lo permite, usa operaciones de “upsert” en lugar de “create”.
Sin idempotencia, un reintento automático puede enviar dos veces la misma factura. Con idempotencia, puedes reintentar con tranquilidad.
Reintentos con criterio
No todos los errores merecen un reintento. Un 401 por credenciales inválidas no se arregla reintentando; un 429 por límite de velocidad sí. La política debería distinguir:
- Errores transitorios: reintentar con backoff exponencial y un máximo de intentos.
- Errores de validación: no reintentar; enviar a una cola de revisión.
- Errores de autenticación: alertar y detener el flujo.
- Errores de negocio: registrar y decidir según la regla del proceso.
En n8n puedes configurar reintentos por nodo y usar un flujo de error dedicado. Lo importante es que el reintento no repita efectos secundarios ya aplicados.
Alertas que no se ignoran
Una alerta por cada error produce fatiga y, tarde o temprano, alguien la silencia. Mejor alertar por patrones:
- tres fallos consecutivos del mismo flujo;
- una ejecución que supera el tiempo máximo esperado;
- un flujo que no se ejecuta en la ventana prevista;
- una cola de pendientes que crece por encima de un umbral;
- un porcentaje de errores superior al normal en una hora.
La alerta debe incluir el nombre del flujo, la ejecución concreta, el error y un enlace para abrirla. Si el equipo tiene que buscar el contexto, la alerta llega tarde.
Observabilidad: logs, métricas y trazas
n8n guarda el historial de ejecuciones, pero eso no siempre es suficiente. Para procesos críticos conviene enviar eventos a un sistema central:
- inicio y fin de cada ejecución;
- identificador de correlación con el sistema de origen;
- duración y número de reintentos;
- resultado y motivo del fallo;
- datos mínimos para reproducir el problema, sin secretos.
Con eso puedes responder “¿qué pasó con el pedido 1234?” sin abrir cinco herramientas.
Un plan de recuperación
Los flujos se caen. La pregunta es cuánto tardas en recuperarlos y si pierdes datos por el camino.
Para cada automatización crítica deberías tener:
- Un procedimiento para pausar el flujo sin perder eventos.
- Una cola o tabla donde queden los eventos pendientes.
- Un comando o flujo para reprocesar un lote concreto.
- Un responsable de revisar la alerta.
- Una prueba periódica de recuperación.
Si el plan solo existe en la cabeza de quien construyó el flujo, no es un plan.
Checklist antes de activar
- □ El flujo tiene una clave de idempotencia.
- □ Los reintentos distinguen errores transitorios de errores permanentes.
- □ Hay un flujo de error que registra el fallo y alerta.
- □ Las credenciales están fuera del workflow y se rotan.
- □ Los límites de la API externa están documentados.
- □ Existe un entorno de staging con datos representativos.
- □ Hay métricas y alertas por patrón, no por ruido.
- □ Alguien sabe cómo reprocesar un lote fallido.
- □ El coste y el volumen están medidos.
En Coderwebs diseñamos e implementamos estas automatizaciones dentro de n8n, incluyendo la capa de integración con APIs y el monitoreo. Si el flujo conecta sistemas críticos, revisamos también la integración de APIs para que los errores no se propaguen en silencio.
Conclusión
La automatización no termina cuando el flujo funciona una vez. Empieza cuando falla y el sistema sabe qué hacer. Idempotencia, reintentos con criterio, alertas por patrón y un plan de recuperación son lo que separa una demo de una operación real.