Historial de n8n: qué guardar y cuándo eliminarlo
El historial de ejecuciones de n8n permite investigar por qué una solicitud no llegó al CRM. Pero también puede conservar mensajes, documentos o respuestas de aplicaciones que el equipo ya no necesita. La decisión útil es definir qué evidencia hace falta para resolver una incidencia y durante cuánto tiempo.
Esta guía propone una revisión para empresas que utilizan n8n en procesos con CRM, ERP o IA. No existe un plazo técnico que sirva para todos: hay que acordarlo con quienes operan el proceso y conocen sus requisitos de conservación.
Empieza por una incidencia realista
Antes de tocar ajustes, plantea una pregunta concreta: «El cliente envió el formulario el viernes; el lunes no aparece en el CRM. ¿Qué necesitamos consultar?». Normalmente interesa relacionar la solicitud con una ejecución, saber dónde se detuvo y comprobar si el destino aceptó la operación.
Diseña un registro operativo mínimo: identificador de solicitud, fecha, flujo y versión, resultado, referencia del registro creado y responsable de la excepción. Es una propuesta de diseño, no un registro que n8n genere automáticamente con todos esos campos. Un identificador interno también puede permitir identificar a una persona; limita quién puede consultarlo.
El mensaje completo y sus adjuntos pueden permanecer en el sistema que corresponda. Duplicarlos en un registro técnico debería responder a una necesidad concreta. Para organizar el aviso al equipo, consulta nuestra guía sobre errores, alertas y reintentos en n8n.
Separa las ejecuciones correctas, fallidas y manuales
Los ajustes de cada workflow permiten decidir por separado si se guardan ejecuciones correctas, fallidas y manuales. Revisa las tres categorías; una prueba lanzada desde el editor también puede usar datos reales.
En un flujo estable, valora si necesitas conservar el detalle de cada éxito. Si dejas de guardarlo, prepara antes otra forma de comprobar el resultado de negocio. No des por hecho que seguirá disponible el mismo historial para investigar o repetir una operación.
Un ejemplo hipotético para acordar la política
Una empresa recibe solicitudes comerciales y las revisa cada mañana laborable. Podría proponer conservar los detalles de errores durante siete días y registrar los resultados correctos mediante referencias en el CRM. Es un ejemplo de trabajo, no una recomendación universal ni un plazo legal. Antes de aplicarlo, debe comprobar fines de semana, ausencias y el tiempo real que tarda en detectar incidencias.
Si soporte necesita el contenido para reproducir un fallo, define quién autoriza ese acceso y cuándo deja de ser necesario. Evita convertir «puede servir algún día» en una política de conservación indefinida.
Comprueba los límites por antigüedad y volumen
En instalaciones propias, las variables de ejecuciones incluyen EXECUTIONS_DATA_PRUNE, EXECUTIONS_DATA_MAX_AGE —en horas— y EXECUTIONS_DATA_PRUNE_MAX_COUNT. Encarga al administrador revisar su valor efectivo y las excepciones de cada flujo.
La limpieza de n8n puede actuar por antigüedad o por cantidad. No garantiza conservar todo hasta el plazo elegido. Las ejecuciones en espera y las anotadas tienen excepciones, y el borrado se realiza por fases. Comprueba estos casos en la versión instalada.
Haz una estimación con el volumen medido, incluyendo picos de importación y reintentos. Si un límite de cantidad permite guardar aproximadamente dos días de actividad, no prometas al equipo una semana de consulta. En n8n Cloud, revisa las condiciones y controles del plan; no presupongas acceso a las variables del servidor.
Ocultar el contenido no equivale a eliminarlo
La función Execution data redaction, disponible en planes Enterprise compatibles, restringe la visibilidad del contenido. No borra ni modifica los datos almacenados. Tampoco sustituye la revisión de lo que el flujo envía a otros sistemas.
Revisa además correos de alerta, capturas adjuntas a tickets, exportaciones y registros propios del código. Una limpieza correcta del historial no demuestra que esas copias hayan desaparecido. Un nodo que elimina campos al final tampoco demuestra que no existan datos de entrada guardados en pasos anteriores.
Las copias de seguridad necesitan su propia política. Si restauras una copia anterior, comprueba qué información vuelve a estar disponible y cómo se aplica de nuevo la conservación acordada. Puedes preparar esa comprobación con nuestra guía de recuperación de n8n.
Valida el cambio con una prueba controlada
Primero, utiliza datos ficticios en un entorno de prueba y provoca una ejecución correcta, otra fallida y una manual. Comprueba qué queda guardado y si soporte puede encontrar el motivo del fallo con la información permitida.
Después, comprueba la limpieza con una muestra preparada para ello, incluidas las excepciones relevantes. No pruebes borrados masivos sobre el historial de producción. Documenta el resultado esperado, la comprobación realizada y quién acepta la pérdida de detalle.
Por último, revisa que las alertas siguen llegando y que el CRM o ERP permite confirmar el resultado. Restaurar el ajuste anterior no recupera ejecuciones que ya se hayan borrado. Guarda la política junto a la documentación del flujo y revísala cuando cambien el volumen, los datos tratados o el proceso de soporte.
Define una conservación que tu equipo pueda mantener
Para revisar una instancia, prepara el inventario de flujos, un ejemplo de incidencia, los volúmenes observados y los sistemas donde se copian datos. No hace falta enviar registros con información de clientes para empezar la conversación.
En Serboweb podemos estudiar la infraestructura, el mantenimiento y las automatizaciones dentro del servicio de n8n administrado. Cuéntanos cómo utilizáis n8n y definiremos el alcance de una revisión de guardado, acceso y recuperación.