Title: Database is not ready! 503 Error - Occurs after ~about 10 hours of inactivity

Questions
1

Describe the problem/error/question

I’m experiencing a recurring “Database is not ready! 503” error that appears after approximately 10 hours of inactivity. The n8n instance works perfectly after deployment, but consistently fails with this error after being idle for extended periods. The root cause is unclear.

What is the error message (if any)?

Database is not ready!
503 Service Unavailable

Please share your workflow

N/A - This is a system-level error occurring before accessing any workflows. The issue prevents access to the n8n UI entirely.

Share the output returned by the last node

N/A - Cannot access workflows due to the 503 error.

Information on your n8n setup

  • n8n version: [Please specify your version]

  • Database: PostgreSQL (Supabase)

  • n8n EXECUTIONS_PROCESS setting: [Please specify if known]

  • Running n8n via: Self-hosted on Google Cloud Run

  • Operating system: Cloud Run container environment

Additional Context

  • The error occurs consistently after ~10 hours of inactivity

  • Restarting the Cloud Run service temporarily resolves the issue

  • The connection to Supabase seems to timeout or disconnect during idle periods

  • Looking for configuration suggestions or similar experiences from the community

Thank you for taking the time to read this. Any insights would be greatly appreciated!

1 Like
2

We have the same problem. I’ve switched a log level to DEBUG and see errors like this:

{
    "error": {
        "message": "timeout exceeded when trying to connect",
        "name": "Error",
        "stack": "Error: timeout exceeded when trying to connect
            at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/[email protected][email protected]/node_modules/pg-pool/index.js:45:11
            at PostgresDriver.obtainMasterConnection (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@[email protected]_@[email protected][email protected][email protected][email protected]/node_modules/src/driver/postgres/PostgresDriver.ts:1181:28)
            at PostgresQueryRunner.query (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@[email protected]_@[email protected][email protected][email protected][email protected]/node_modules/src/driver/postgres/PostgresQueryRunner.ts:248:36)
            at SelectQueryBuilder.loadRawResults (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@[email protected]_@[email protected][email protected][email protected][email protected]/node_modules/src/query-builder/SelectQueryBuilder.ts:3660:25)
            at SelectQueryBuilder.executeEntitiesAndRawResults (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@[email protected]_@[email protected][email protected][email protected][email protected]/node_modules/src/query-builder/SelectQueryBuilder.ts:3406:26)
            at SelectQueryBuilder.getRawAndEntities (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@[email protected]_@[email protected][email protected][email protected][email protected]/node_modules/src/query-builder/SelectQueryBuilder.ts:1661:29)
            at SelectQueryBuilder.getMany (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@[email protected]_@[email protected][email protected][email protected][email protected]/node_modules/src/query-builder/SelectQueryBuilder.ts:1751:25)
            at ExecutionRepository.findSoftDeletedExecutions (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+db@file+packages+@n8n+db_@[email protected]_@opentelemetry+sdk-trace-base@1._4f71e79debd90f68b8a49d1bf4d1af69/node_modules/@n8n/db/src/repositories/execution.repository.ts:595:4)
            at ExecutionsPruningService.hardDelete (/usr/local/lib/node_modules/n8n/src/services/pruning/executions-pruning.service.ts:134:15)"
    },
    "file": "executions-pruning.service.js",
    "scopes": [
        "pruning"
    ]
}
3

lepus_timidus

Thank you for your response.
By the way, are you using the free superbase plan?

4

Yes, Self-hosted free version.

1 Like
5

I have the same problem since version 1.118 i believe

1 Like
6

It’s been a while.
503 - Problem temporarily resolved!
The problem stopped occurring after I switched to Supabase Pro Plan.
There may have been some restrictions.

7

Is there any official N8N statement that it’s a Free version limitation?

8

There are no official reasons for this.
When I used Cloud SQL in the same environment in the past, I didn’t get a 503 error, so I thought there might be a problem with my SuperBase environment, and when I switched to the pro version, it was resolved.
Admittedly, there’s no basis for this claim, and it might just be my own personal experience.
Sorry.

9

Got it. But I have a similar experience, meaning that after upgrading to a newer version I started getting 503. I changed the configuration to min_instances=1 to avoid cold starts, hope that might help.