Tenemos un problema con webhooks en múltiples workflows. Hay múltiples ocasiones, siempre alrededor de las 12:00AM/PM ~12:20AM/PM, donde algunos webhooks simplemente no son invocables y n8n lanza “There was a problem executing the workflow” (Hubo un problema ejecutando el workflow). O el backend se ejecuta en un timeout, sin registros de ejecución (aunque el registro de ejecuciones está activado). No hay más mensaje de error, solo este genérico. ¿Hay un lugar donde pueda ver más información sobre este error en mi instancia de n8n?
El único lugar para encontrar el error «real» está en los Render.com Service Logs.
Qué buscar: Ve a tu Render Dashboard →→ tu servicio de n8n →→ Logs.
Palabras clave específicas: Busca SQLITE_BUSY, database is locked, Out of Memory, Killed o Segmentation fault alrededor de las marcas de tiempo 12:00 AM/PM.
Consejo profesional: Para obtener aún más detalle, añade la variable de entorno N8N_LOG_LEVEL=debug en tu configuración de Render y reinicia. Esto forzará a n8n a imprimir eventos internos más detallados en los logs de Render.
Basándome en tu descripción, este comportamiento generalmente es causado por una de dos cosas: Bloqueo de base de datos o Agotamiento de memoria (OOM).
Esta es la solución recomendada:
Migra a PostgreSQL: SQLite no está diseñado para concurrencia en producción. Render proporciona una base de datos PostgreSQL administrada. Migrar a Postgres elimina completamente el problema del «bloqueo de escritura» y es la recomendación estándar para cualquier instancia de n8n que maneje webhooks en producción. Resolverá permanentemente los tiempos de espera de las 12:00 y los errores genéricos de «problema al ejecutar».
Disculpa, cometí un error, ya estamos usando Postgres.
La memoria tampoco se dispara en esos momentos y no hay otras entradas de registro en el servicio de render aparte de los mensajes «There was a problem executing the workflow».
@Florian_Glappa Esperaría que ese error desencadenara algo en los registros de n8n. ¿Es posible que Render realice una copia de seguridad/instantánea alrededor de la medianoche? Una ventana de 20 minutos alrededor de la misma hora sugiere algo más relacionado con el entorno que con un error del lado de la aplicación.
Complementando el ángulo ambiental de Jon, hay también un patrón del lado de la aplicación que se ajusta exactamente a tus síntomas y aún no ha sido mencionado: 0 0,12 * * * es una de las expresiones cron más comunes que existen. Si algún workflow en tu instancia (no solo los que fallan) tiene un Schedule Trigger disparándose a las 00:00 y las 12:00, un trabajo pesado dos veces al día puede saturar brevemente la instancia, y los webhooks entrantes son lo que falla visiblemente. Vale la pena hacer un inventario rápido de cada Schedule Trigger en todos los workflows, luego revisar la lista de ejecuciones filtrada a esas ventanas: ¿hay siempre una ejecución programada en vuelo cuando los webhooks mueren?
Lo segundo que coincide con tu «sin datos de ejecución registrados a pesar de tener guardado habilitado»: agotamiento del pool de conexiones de Postgres. El pool por defecto de n8n por proceso principal es pequeño, y cuando varias ejecuciones comienzan al mismo momento el pool se seca — las nuevas ejecuciones pueden fallar antes de que n8n logre escribir algo en la tabla de ejecuciones, y el error vuelve al llamador del webhook sin que mucho aterrice en los logs del servicio. Eso explicaría por qué ves casi nada en los logs de Render. Dos comprobaciones: aumenta DB_POSTGRESDB_POOL_SIZE (por ejemplo a 10) y ve si el patrón cambia, y busca los logs del lado de Postgres (los logs de la base de datos de Render, no los logs del servicio n8n) para errores de conexión o picos de latencia en esas ventanas — una copia de seguridad de la base de datos administrada también aparecería allí, lo que confirmaría la teoría de Jon sin adivinar.
Y ya que es tan predecible: obsérvalo en vivo una vez. docker logs -f (con debug activado, como sugirió kjooleng) desde las 11:55 hasta las 12:25 te dirá más que un día de historial, además filtra la lista de ejecuciones por estado «crashed» — esos no siempre aparecen donde esperas.
Si el inventario de cron encuentra un trabajo dos veces al día, la solución usual es simplemente trasladarlo a una hora impar (estilo 03:17) y agruparlo. Escalonar horarios en minutos impares es un buen hábito en cualquier n8n de instancia única de todas formas.
¡Hey, esa fue una pista muy buena, gracias! Encontré un cron que se ejecuta a las 00:05 y 12:05 que normalmente tarda 15 minutos y consumía una cantidad ridicula de memoria. Lo refactoricé ahora, creo que era eso. ¡Muchas gracias!
