Nota revisada y reescrita el 18 de octubre de 2026: la versión original tenía errores y datos sin fuente.
En octubre de 2026, el workflow que generaba las notas de esta web llevaba casi dos semanas fallando en cada ejecución programada, mientras las pruebas manuales salían bien. Había dos causas, y ninguna era un bug de n8n: la ejecución programada corría una versión vieja del workflow, y la API de IA a la que llamaba rechazaba las peticiones a esa hora. Esto es lo que revisaría en cualquier workflow que funciona "a mano" y falla solo.
1. ¿Qué versión se está ejecutando?
En n8n 2.x, guardar y publicar son cosas distintas. Los cambios se guardan como borrador, y los triggers (cron, webhook) ejecutan la última versión publicada. En el editor ves y pruebas el borrador. Es fácil pasar días probando una versión mientras la programada ejecuta otra.
Para comprobarlo, en Executions, abre una ejecución programada y mira sus nodos. En mi caso, la ejecución de producción tenía 5 nodos y el editor 20: corría una versión de abril. La solución fue pulsar Publish. Después de publicar, comprueba que la versión activa es la que acabas de guardar.
2. Leer el error de verdad
Las ejecuciones fallidas muestran el nodo y el mensaje. Los míos eran dos:
The service is receiving too many requests from you(HTTP 429): límite de peticiones. A la misma hora corría otro workflow que usaba la misma clave de la API y la misma cuota gratuita.Service unavailable/ model is experiencing high demand (HTTP 503): el proveedor estaba saturado. No era culpa del workflow.
El primero se arregla separando los horarios. El segundo, reintentando más.
3. Reintentos por nodo
En los Settings de cada nodo que llama a algo externo:
- Retry On Fail: activado.
- Max Tries: el número de intentos. Yo tenía 2, que no da para superar un pico de demanda. El motor de n8n lo limita a un máximo de 5: aunque pongas más, no hará más.
- Wait Between Tries: la espera entre intentos, con un máximo de 5.000 ms. El motor también recorta ese valor.
Con 5 intentos y 5 segundos cubres unos 20 segundos de fallo. Si los cortes de tu proveedor duran minutos, los reintentos del nodo no llegan. En ese caso, conecta la salida de error a un nodo Wait y vuelve a intentarlo, o ten un modelo de respaldo.
4. Salida de error en el nodo
En Settings → On Error, la opción Continue (using error output) añade una segunda salida al nodo por la que salen los items que fallan. Con ella puedes:
- Llamar a un modelo alternativo si el principal falla.
- Guardar el item fallido en una hoja o una tabla para reprocesarlo.
- Seguir con el resto de items en lugar de parar todo el lote.
5. Enterarte cuando falla
Un workflow que falla en silencio es peor que uno que no existe. n8n tiene el nodo Error Trigger: crea un workflow que empiece por él y mande un aviso (email, Telegram, una notificación push), y asígnalo en Workflow Settings → Error Workflow de cada workflow importante. Recibe el nombre del workflow, el nodo, el mensaje y el enlace a la ejecución.
6. Mantenimiento de la instancia autoalojada
- Historial de ejecuciones: n8n borra las antiguas automáticamente según
EXECUTIONS_DATA_MAX_AGE(en horas). Si guardas el detalle completo de cada ejecución, la base de datos crece rápido. Ajusta qué se guarda en Workflow Settings. - Timeouts:
EXECUTIONS_TIMEOUTpone un tiempo máximo global por ejecución, para que un workflow colgado no se quede corriendo para siempre. - Copias de seguridad de la base de datos y de la clave de cifrado (
N8N_ENCRYPTION_KEY). Sin esa clave no puedes descifrar las credenciales guardadas.