Cascading Docker Failures: When a Node.js Heap Limit in NocoDB Starved an n8n Automation Stack
The morning the automation board turned red
The failure appeared during a routine system inspection on a self-hosted automation node. The n8n administration dashboard reported dozens of workflow failures overnight:
NodeApiError: connect ECONNREFUSED 192.168.1.1:10380
at Object.request (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/adapters/http.js:64:14)
at processTicksAndRejections (node:internal/process/task_queues:95:5)Every integration responsible for syncing Telegram registrations, form submissions, and customer inquiries into the central database was failing. In addition, several scheduled batch jobs were marked as permanently running, accumulating memory without making progress.
Checking the health of the target service—NocoDB on port 10380—confirmed that the container was not serving traffic. It was caught in a restart crash loop.
Root cause: the default V8 heap ceiling
Inspecting the container logs via Portainer revealed an explicit Node.js runtime crash:
<--- Last few GCs --->
[1:0x55d7b8a8b000] 184201 ms: Mark-sweep (reduce) 712.4 (724.8) -> 710.2 (725.1) MB, 412.5 / 0.0 ms
[1:0x55d7b8a8b000] 184712 ms: Mark-sweep (reduce) 715.1 (725.1) -> 714.8 (726.0) MB, 511.0 / 0.0 ms
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 0xb83a30 node::Abort() [node]
2: 0xa94415 node::FatalError(char const*, char const*) [node]
3: 0xd45062 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]When NocoDB had been provisioned in Docker Compose, the container had been given a strict cgroup limit:
services:
nocodb:
image: nocodb/nocodb:latest
mem_limit: 768mUnder a tight 768 MB cgroup boundary, V8’s default heap heuristics leave insufficient headroom for spiky aggregation workloads. Under complex aggregation queries and table joins across tens of thousands of rows, memory usage expanded beyond 700 MB. The V8 garbage collector attempted aggressive mark-sweep cycles, failed to reclaim enough contiguous pages, and triggered a fatal abort.
When NocoDB died, every dependent n8n workflow experienced connection refused errors. Because n8n had retry policies configured on its database nodes, hundreds of retries hammered the port simultaneously as Docker restarted the container, creating an avalanche of queued requests that re-triggered the OOM crash within seconds of boot.
The fix: memory alignment and orphan cleanup
Resolving the cascade required addressing both the container headroom and the runtime heap sizing:
🔍 docker-compose.yml — NocoDB memory configuration (17 lines)
services:
nocodb:
image: nocodb/nocodb:latest
container_name: nocodb-server
restart: unless-stopped
environment:
- NC_DB=pg://postgres:5432?u=...
- NODE_OPTIONS=--max-old-space-size=1536
deploy:
resources:
limits:
memory: 2048M
reservations:
memory: 512M
ports:
- "10380:8080"By setting NODE_OPTIONS: "--max-old-space-size=1536" alongside a 2048 MB Docker memory ceiling, V8 was given 1.5 GB of user-space heap while leaving 512 MB of container memory for native bindings, libuv buffers, and OS overhead.
Next, the database state in n8n was cleaned up. Long-running executions that had stalled during the database outage were identified in the orchestration storage and marked as failed so worker threads could release their execution locks.
The result
Following the stack restart and configuration alignment:
- NocoDB initialized cleanly, reporting
{"message":"OK"}on its/api/v1/healthendpoint. - Webhook events and data pipelines processed without a single connection drop.
- Host memory on the container host stabilized without further OOM kills.
- The automation failure counter dropped back to zero and stayed clean across subsequent batch cron cycles.
Want a 24/7 bot or automation pipeline that never drops a lead?
Don't let customer inquiries slip away at midnight or on weekends. I build custom Telegram/WhatsApp AI assistants and deterministic workflows that connect directly to your catalogue, CRM, and order fulfillment.
