Schedule Trigger ejecuta docenas de ejecuciones concurrentes al inicio en lugar de una

Describe el problema/error/pregunta

Hola a todos,
Estoy teniendo un problema con los Schedule Triggers que generan demasiadas ejecuciones y no sé cómo solucionarlo.
Lo que hace mi flujo de trabajo:
Tengo un sistema de automatización de atención al cliente. Cuando un cliente envía una solicitud de soporte, los datos van a una hoja de Google. Un gerente luego revisa la solicitud y rellena una columna “Decision” (aceptado / rechazado / escalada).
Tengo 3 flujos de trabajo, cada uno consultando una pestaña diferente de la hoja de Google cada 2 minutos:

  • Schedule Trigger (cada 2 min)
  • Obtener todas las filas de la hoja de Google
  • Nodo Code: filtrar filas donde la columna Decision acaba de ser rellenada Y aún no ha sido procesada
  • Nodo Switch: enrutar según el valor de la decisión
  • Acciones: enviar email al cliente, actualizar estado de la hoja, crear ticket de soporte, etc.
    Así que la mayoría del tiempo, el flujo de trabajo se ejecuta, no encuentra nada que hacer y se detiene. Solo cuando el gerente rellena una decisión es que realmente hace algo.
    El problema:
    Estoy viendo demasiadas ejecuciones acumulándose. Cuando el servidor se reinicia, obtengo un gran aumento — docenas de ejecuciones todas en exactamente la misma marca de tiempo, una mezcla de Errores (~40s) y Cancelados (~1m7s).
    Creo que n8n podría estar intentando “ponerse al día” con todas las ejecuciones programadas perdidas mientras el servidor estuvo caído. O tal vez el trigger se dispara múltiples veces concurrentemente antes de que la ejecución anterior termine.
    Mis preguntas:
  1. ¿Cómo puedo prevenir este aumento de ejecuciones al iniciar?
  2. ¿Hay una forma de limitar las ejecuciones concurrentes por flujo de trabajo?
  3. ¿Es una buena idea consultar hojas de Google cada 2 minutos con un Schedule Trigger, o hay un patrón mejor para este caso de uso?
    ¡Muchas gracias!

¿Cuál es el mensaje de error (si lo hay)?

Por favor comparte tu flujo de trabajo

Comparte el resultado devuelto por el último nodo

Información sobre tu configuración de n8n

@Arthur_Mascot el burst inicial se pierde en las ejecuciones perdidas — el Schedule Trigger se dispara una vez por cada intervalo perdido por defecto cuando n8n vuelve a estar en línea. hay una configuración para deshabilitarlo en el nodo disparador mismo. pero antes de los detalles específicos — ¿estás en n8n cloud o auto-hospedado? los controles de ejecución concurrente son diferentes según el entorno. también vale la pena señalarlo: Google Sheets tiene una operación de nodo Trigger que observa cambios de filas de forma nativa, mucho más eficiente que hacer polling cada 2 min, pero solo si tu versión lo expone.

Supongo que estás usando modo principal, @Arthur_Mascot.
¿Qué pasaría si cambias a modo de cola?

¡Hola @Arthur_Mascot! ¡Bienvenido!
¿Has intentado eliminar todo el flujo de trabajo e importarlo nuevamente? De esta forma obtendrá un nuevo ID y se limpiarán las ejecuciones fantasma. Puedes reducir el número de ejecuciones concurrentes en tu instancia, no por flujo de trabajo supongo.

Y mirando tu flujo de trabajo, es una mejor opción agregar un disparador de Google Sheets en lugar de consultar todo cada vez y agregar nodos de espera entre ellos

Para el parámetro en Schedule Trigger — ¿dónde exactamente se encuentra la configuración para desactivar la recuperación de ejecuciones perdidas? No la veo en los settings del nodo.

Muy interesado también en el enfoque Google Sheets Trigger — justamente mi workflow filtra exactamente en la columna “Decisión”: recupera todas las filas con el estado en_espera_validacion y verifica si la columna “Decisión” ha sido rellenada. ¿Puede el trigger nativo monitorear específicamente esta columna y dispararse solo cuando se añade un nuevo valor en ella?

¡Hola, gracias! :wink: ¿Cómo hago esto?

Puedes leer aquí

¡Bienvenido @Arthur_Mascot a nuestra comunidad! Soy Jay y soy un creador verificado de n8n.

Para desactivar la recuperación, abre tu nodo Schedule Trigger y busca el toggle “Fire on startup catch-up” - está en el panel de configuración del nodo. Desactívalo y n8n dejará de intentar ejecutar todos los intervalos perdidos al reiniciar. Esta es la solución más limpia para tu caso de uso ya que estás consultando cada 2 minutos y un pico de recuperación no tiene sentido para una cola de soporte.

Gracias, pero no lo encuentro :slight_smile:

@Arthur_Mascot ¿en qué versión estás? esta es la v2.21.7

@Arthur_Mascot otro punto, la configuración de la cola no es en el nodo, sino en la configuración del flujo de trabajo.
mira esta documentación
Configuring queue mode | n8n Docs

@Arthur_Mascot la opción «Fire on startup catch-up» se encuentra en el nodo Schedule Trigger bajo la pestaña Settings (no en la pestaña Parameters). Abre el nodo, cambia a la pestaña Settings en la parte superior y deberías verla allí. Si estás en la versión v2.21.7 y no la ves, es posible que ese toggle se haya añadido en una versión posterior - en ese caso, la alternativa es establecer WORKFLOWS_QUEUE_STARTUP a false en tus variables de entorno, o simplemente reinicia n8n durante una ventana de baja actividad e inicia manualmente el workflow una vez después del reinicio.