Algunos flujos de trabajo no muestran ejecuciones en absoluto, aunque se ejecutan a veces cada hora, pero no aparece nada. Sin filtros establecidos, sin limitaciones en la interfaz.
Otros flujos de trabajo tienen un historial de ejecución muy activo.
He visto algunos posts sobre este problema, pero la mayoría de ellos no llevan a una solución. La única solución alternativa no aplica en mi caso.
Los valores de configuración se aumentaron en el backend, pero el problema no se resolvió. También he verificado y comparado la configuración de flujos de trabajo de varios que sí tienen ejecuciones y otros que no. Cuando los disparo manualmente, las ejecuciones existen y se registran.
Estoy comenzando a pensar que alguien utilizó la URL del webhook de prueba en lugar de la de producción, o tal vez en la aplicación configuraron GET cuando debería ser POST… Pero necesito estar seguro de que no hay nada más mal con n8n, la configuración y el servidor.
Si fueron eliminados, entonces al menos deberían mostrar algo en ejecuciones.
¿Cómo es esto posible? ¿Alguien ha tenido este problema antes? ¿Cómo lo resolviste?
Información sobre tu configuración de n8n
Versión de n8n: Version 2.8.3
Base de datos (predeterminado: SQLite): PostgreSQL (Docker)
Configuración de EXECUTIONS_PROCESS de n8n (predeterminado: own, main): main
Ejecutar n8n a través de (Docker, npm, n8n cloud, app de escritorio): npm
Sistema operativo: alojado en Ubuntu 24.04.4 LTS, interfaz en Chrome/Windows 10/11
Tu teoría sobre la URL del webhook vale la pena verificar, pero primero revisa algo más simple: cada flujo de trabajo puede anular la configuración global de guardado de ejecuciones.
Abre un flujo de trabajo afectado → Configuración (icono de engranaje) → marca “Guardar ejecuciones de producción exitosas” y “Guardar ejecuciones de producción fallidas.” Si estas opciones están configuradas como “No guardar” en los flujos de trabajo afectados, las ejecuciones funcionan bien pero nada se registra. Los flujos de trabajo que sí muestran historial probablemente tienen estas opciones configuradas como “Predeterminado” o “Guardar.”
Si eso se ve bien, verifica tu configuración de webhook:
Asegúrate de que el flujo de trabajo esté publicado.
Haz clic en el nodo Webhook y compara la URL de producción con lo que está llamando el sistema externo. Si está usando la URL de prueba, las ejecuciones solo funcionan mientras el editor esté abierto.
Confirma que el método HTTP coincida (GET vs POST).
Comienza con la configuración de guardado por flujo de trabajo ya que es la causa más común de “funciona pero sin historial.”
Los flujos de trabajo se han publicado.
La configuración está habilitada en los flujos de trabajo para guardar las ejecuciones.
Aguardando comentarios del equipo sobre las URLs y métodos HTTP utilizados.
Si la URL del webhook (URL del webhook de prueba en lugar de la de producción) o el método HTTP es incorrecto, entonces no verás nada en la lista de ejecuciones en absoluto.
Ambos problemas generarán un mensaje de éxito del lado del cliente con un código de estado 404, y nada se almacenará en las ejecuciones.
Una cosa rápida que vale la pena descartar antes de ajustar más configuración: ¿los flujos de trabajo se disparan realmente o se disparan pero no se guardan? Fácil de distinguir: observa los registros de n8n justo cuando debería ejecutarse la programación. Los hits de webhook se muestran en stdout por defecto; para disparos de disparadores necesitas N8N_LOG_LEVEL=debug. Si ves que el disparador se activa pero ninguna fila aparece en execution_entity, es un problema de ruta de guardado. Si no ves nada en absoluto en la hora programada, no se está disparando en primer lugar.
Dos culpables comunes y silenciosos: el toggle de Activo desactivado (los flujos de trabajo guardados pero inactivos se ven idénticos en la lista, fácil de pasar por alto entre varias docenas), o el podado de ejecución global que recorta ejecuciones si tienes muchas programaciones por hora. Vale la pena descartar esos antes de hacer algo más sofisticado.
El problema ha sido identificado. El problema es que los workflows tienen alrededor de 17k ejecuciones diarias. Aumentar el valor predeterminado de 10k y 7 días a 50k y 30 días tuvo poco efecto, ya que después de 3 días la poda ya había comenzado (límite de 50k). Esto causó que las ejecuciones de bajo volumen se prunaran y las de alto volumen permanecieran. El límite de 50k se aplica a todos los workflows, no a los individuales.
Ahora tengo 3 opciones. ¿Cuál me recomiendas?
1.) Establecer el límite de ejecución en 250k, lo que probablemente requerirá un tamaño de disco mayor para almacenarlos
2.) Desactivar el límite de tamaño y usar solo poda basada en tiempo (30 días). Esto también requerirá un tamaño de disco mayor
3.) Por último, actualizar la configuración del workflow de los workflows más activos para almacenar solo ejecuciones fallidas, u optimizarlos para reducir la cantidad de ejecuciones.
Desactivar la poda completamente no tiene sentido.
[EDIT] la cantidad de workflows crecerá y las ejecuciones mensuales son alrededor de 517k, no creo que establecer el límite en 750k sea el camino
Hola dmtr - con el nuevo detalle, esto parece menos un problema de webhook/URL de prueba y más un problema de dimensionamiento de ejecución-retención: aproximadamente 17k ejecuciones/día significa que un límite de recuento global de 50k puede comenzar a eliminar después de aproximadamente tres días, y el recuento se comparte entre flujos de trabajo en lugar de estar reservado por flujo de trabajo.
El tradeoff no es solo “aumentar el límite” vs “deshabilitar el límite”; se trata de decidir qué flujos de trabajo merecen almacenamiento de historial de éxito y cuáles solo deberían mantener ejecuciones fallidas.
Puedo convertir esto en un pequeño mapa de retención de poda de ejecución de n8n para que tengas una decisión más clara antes de aumentar el disco o cambiar los límites globales.
Lo mantendría reducido: sin acceso de n8n, sin acceso a servidor/base de datos, sin exportaciones de flujos de trabajo reales, sin registros de producción, sin credenciales, y sin cambios de almacenamiento. Puedo trabajar a partir del hilo público, números de volumen de flujo de trabajo falsos, configuraciones de retención falsas, y solo documentación pública de n8n.
Por USD 49 puedo enviar:
una tabla de decisión de retención para tus tres opciones,
una verificación de cordura de dimensionamiento simple de 17k/día y 517k/mes,
una regla de clasificación por flujo de trabajo “guardar éxito vs solo fallidos”,
un plan de implementación para cambiar primero los flujos de trabajo de alto volumen,
una nota de riesgo breve para crecimiento de disco, necesidades de auditoría/depuración, y sorpresas de poda.
Si eso funciona, responde “sí - mapa de poda” y solo envía ejemplos de volumen de flujo de trabajo falsos/redactados, no registros reales, credenciales, exportaciones de flujos de trabajo, o acceso a servidor.
Límite: No puedo procesar pagos, configurar detalles de pago/KYC/cuenta, acceder a n8n o tu servidor, manejar credenciales o claves API, inspeccionar flujos de trabajo/registros privados, cambiar configuraciones de poda, cambiar el tamaño de discos, o contar nada a menos que estén presentes los cinco campos de compromiso requeridos.
