We have a problem with webhooks over multiple workflows. There are multiple occurences, always around 12AM/PM ~ 12:20AM/PM, where some webhooks are just not callable and n8n throws “There was a problem executing the workflow”. Or backend runs in a timeout, no execution is recorded (even though recording of executions is turned on). There is no more error message, just this generic one. Is there a place where i can see more information about this error on my n8n instance?
The only place to find the “real” error is in the Render.com Service Logs.
What to look for: Go to your Render Dashboard →→ your n8n service →→ Logs.
Specific Keywords: Search for SQLITE_BUSY, database is locked, Out of Memory, Killed, or Segmentation fault around the 12:00 AM/PM timestamps.
Pro Tip: To get even more detail, add the environment variable N8N_LOG_LEVEL=debug to your Render settings and restart. This will force n8n to print more verbose internal events to the Render logs.
Based on your description, this behavior is typically caused by one of two things: Database Locking or Memory Exhaustion (OOM).
This is the recommended fix:
Migrate to PostgreSQL: SQLite is not designed for production concurrency. Render provides a managed PostgreSQL database. Migrating to Postgres removes the “write lock” issue entirely and is the standard recommendation for any n8n instance handling production webhooks. It will solve the 12:00 timeouts and the generic “problem executing” errors permanently.
Sorry, i made a mistake, we are already using Postgres.
Memory also does not spike at those times and there are no other log entries in the render service as those “There was a problem executing the workflow” ones.
@Florian_Glappa I would expect that error to trigger something in the n8n logs, Is it possible that Render takes a backup / snapshot at around midnight? A 20 minute window around the same sort of time points towards something environmental rather than an application side bug.
Adding to Jon’s environmental angle — there’s also an application-side pattern that fits your exact symptoms and hasn’t been mentioned yet: 0 0,12 * * * is one of the most common cron expressions in existence. If any workflow on your instance (not just the failing ones) has a Schedule Trigger firing at 00:00 and 12:00, a heavy twice-daily job can briefly saturate the instance, and incoming webhooks are what fail visibly. Worth a quick inventory of every Schedule Trigger across all workflows, then check the executions list filtered to those windows: is a scheduled run always in flight when the webhooks die?
The second thing that matches your “no execution data recorded despite saving enabled”: Postgres connection pool exhaustion. n8n’s default pool per main process is small, and when several executions start at the same moment the pool runs dry — new executions can then fail before n8n manages to write anything to the executions table, and the error goes back to the webhook caller without much landing in the service logs. That would explain why you see almost nothing in Render logs. Two checks: raise DB_POSTGRESDB_POOL_SIZE (e.g. to 10) and see if the pattern changes, and look at the Postgres-side logs (the Render database’s logs, not the n8n service logs) for connection
errors or latency spikes in those windows — a managed-DB backup would also show up there, which would confirm Jon’s theory without guessing.
And since it’s so predictable: watch it live once. docker logs -f (with debug on, as kjooleng suggested) from 11:55 to 12:25 will tell you more than a day of scrollback, plus filter the executions list by status “crashed” — those don’t always show where you expect.
If the cron inventory turns up a twice-daily job, the usual fix is just moving it to an odd time (03:17-style) and batching it. Staggering schedules at odd minutes is a good habit on any single-instance n8n anyway.
Hey, this was a really good hint, thanks! I found a cron starting at 00:05 and 12:05 which usually runs 15 mins and used ridicolous amount of memory. I refactored this now, I think this was it. Thanks a lot!
