Haz que tus disparadores de facturación funcionen tras un reinicio: auditoría n8n 2.45 para un operador en solitario

Un reinicio es la verdadera prueba

Cuando tu servidor se reinicia, el recordatorio de factura se dispara tarde o no se dispara. Esa es la única pregunta que importa para un disparador de facturación. Para un negocio en solitario, ese recordatorio, la verificación de facturación y el seguimiento con el cliente no son automáticos hasta que los has visto sobrevivir a un reinicio. n8n lanzó la versión 2.45.0 el 20 de octubre de 2026. A partir de esa versión, el planificador duradero es el predeterminado. Escribe cada ejecución programada en la base de datos antes de que llegue su hora, de modo que un reinicio no la descarte. Si la inactividad supera una ejecución vencida, aún puede ejecutarse tarde siempre que el período de gracia no haya cerrado; una vez que lo hace, la regla de fallo del disparador toma el control.

Un reinicio es el momento en que un flujo de trabajo deja de ser un diagrama y se convierte en un evento real. Un recordatorio de factura matutino puede llegar tarde en lugar de desaparecer. Una verificación de facturación puede ejecutarse después de su hora límite, y una ejecución tardía puede duplicar trabajo. El planificador hace posible la ejecución tardía; tu flujo de trabajo aún debe gestionarla. Para un operador en solitario, el valor está en el margen: un seguimiento perdido se convierte en un seguimiento tardío, no en una pérdida silenciosa.

Un predeterminado mejorado aún te deja responsable de saber qué disparadores tocan los ingresos. La inactividad puede exponer un flujo de trabajo que dependía en silencio de viejos hábitos de temporización. La auditoría que sigue es el truco duradero: prueba la ruta de reinicio una vez y luego confía en la programación con menos ansiedad.

Realiza la auditoría de supervivencia ante reinicio en cinco puntos antes de confiar en la programación

Mantén la lista lo suficientemente corta como para repetirla tras una actualización. Cada punto debe tomar minutos, y el resultado debe ser una nota que puedas leer más tarde sin abrir el flujo de trabajo. Autoalojar la instancia convierte la auditoría en una herramienta de margen. Una programación puede generar seguimientos adicionales: una factura que no se envió, un cliente que no recibió respuesta, una discrepancia de facturación que necesita explicación. La auditoría no elimina el trabajo que una programación crea; impide que ese trabajo llegue todo a la vez tras la inactividad. Protege las horas que gastarías persiguiendo una ejecución perdida.

• Enumera cada disparador de facturación. Anota cada flujo de trabajo programado que envía facturas, verifica la facturación, hace seguimiento con clientes o registra ingresos. Una nota breve es suficiente; el punto es ver el alcance completo.
• Anota la programación y el período de gracia. Para cada disparador, registra cuándo debe ejecutarse y cuánto tiempo puede tardar antes de considerarse perdido.
• Lee la política de fallos. Decide qué ocurre tras el período de gracia, haz la respuesta explícita y alinéala con la consecuencia de negocio. Una política poco clara deja el flujo de trabajo sin probar.
• Prueba un reinicio o una ejecución retrasada. Detén la instancia, deja pasar una ejecución programada y luego vuelve a iniciarla. Confirma si la ejecución tardía aparece y si el flujo de trabajo se comporta como esperas.
• Elimina suposiciones de temporización legada. Borra notas, comentarios o hábitos que asuman el antiguo comportamiento de temporización. Un flujo de trabajo que necesite ese comportamiento debe marcarse para un cambio de configuración deliberado en lugar de adivinar.

La visibilidad va primero. No puedes juzgar un reinicio si no sabes qué disparadores importan, cuánto pueden tardar y qué ocurre cuando se retrasan demasiado. La prueba es la parte que hace real la auditoría. La limpieza mantiene la próxima auditoría limpia. El trabajo de ingresos merece una nota que sobreviva a la próxima actualización, no un detalle que desaparezca más tarde.

Las suposiciones de temporización legada son ahora una carga

n8n 2.45.0 eliminó la opción de nodo Skip Durable Scheduler y la variable de entorno N8N_ENV_FEAT_SKIP_DURABLE_SCHEDULER. También eliminó la configuración N8N_SCHEDULER_MIN_INTERVAL sin uso. n8n puede mantener el anterior comportamiento de temporización alineada al reloj estableciendo N8N_SCHEDULER_TRIGGER_NODE_MODE=legacy.

Estas eliminaciones son pequeñas en las notas de versión y grandes en la práctica. Te obligan a dejar de tratar el planificador duradero como un conjunto de predeterminados ocultos. Un flujo de trabajo que dependa del antiguo comportamiento debe tener esa dependencia visible, nombrada y fácil de eliminar más tarde. Sin esa dependencia, el flujo de trabajo puede dejarse en paz.

No dejes el modo legada como una excepción silenciosa. Úsalo solo con una nota que nombre el flujo de trabajo y la razón. Sin esa nota, la próxima persona que toque la instancia asumirá que la programación es simple, y esa suposición es exactamente lo que un reinicio puede romper.

Corrige el disparador antes de añadir otra automatización cuando un flujo de trabajo no supera la prueba. Ejecuta la auditoría tras la actualización y de nuevo tras cualquier cambio en un disparador de programación. Mantén las notas juntas. Cuando una programación se comporte mal, sabrás si el problema es el disparador, la política de fallos o una suposición legada.