Hello everyone,
We are currently experiencing an issue with our n8n instance. Since approximately 10:05 AM, all users in our organization have been unable to access the platform. Whenever we try to open any page, we receive the following error message: {"code":503,"message":"Database is not ready!"}. The problem is affecting all users and preventing access to workflows, executions, and other areas of the system. We are not aware of any recent changes that could have caused this behavior. Could someone please help investigate or advise on the next steps? Any assistance would be greatly appreciated, as this issue is impacting our operations.
Thank you.
Hi @Pedro_Lima1
The error message you are seeing basically means that while the n8n application is running, it cannot “talk” to the database where all your workflows and settings are stored. Because the app can’t access its memory, it cannot load any pages or run any tasks, which is why the entire organization is blocked.
The first step is to check if the database is actually turned on. Sometimes the service that manages the data crashes or gets stuck in a loop of restarting itself. You need to verify that the database is active and hasn’t simply shut down.
Another common cause for this issue is a full hard drive. If the server has run out of storage space, the database will often stop working because it has nowhere to write new information or temporary files. Checking the available disk space is a quick way to see if the system is “choking” due to a lack of room.
To find the exact cause, you should look at the system logs. These are like a digital diary where the computer records every error it encounters. By reading these logs, you can find the specific reason—such as a connection timeout or a configuration error—that is triggering the “not ready” message.
If your database is hosted on a separate server from your n8n application, there might be a communication breakdown between them. This could be caused by a sudden network glitch or a security firewall that has started blocking the path between the two systems.
As a final attempt, restarting both the database and the n8n instance may clear any temporary glitches or memory leaks. To provide more specific help, it would be useful to know how you installed n8n and which database you are using, as the fix differs depending on your setup.
1 Like
Hi @Pedro_Lima1 — to speed up the diagnosis, can you share how n8n is deployed (Docker Compose, standalone Docker, npm/pm2)?
If you’re on Docker, these two commands will usually show the root cause immediately:
docker logs <your-n8n-container> --tail 50
docker logs <your-db-container> --tail 30
The most common triggers for this specific error:
- Postgres/MySQL container crashed or not started — check
docker ps -a to confirm your DB container is actually running (not just “Exited”)
- Disk full — run
df -h on the host; n8n’s database will refuse connections if the volume has 0 bytes free
- DB init still in progress — on a fresh start, Postgres can take 10–30 seconds to accept connections; n8n starts hitting it immediately and throws this error until it’s ready
If you see the DB container in a crash loop in the logs, that’s the real issue to fix first — no amount of restarting n8n will help until the database itself is healthy.
A 503 “Database is not ready” across all users means n8n is up but cannot reach its database, so the whole instance is blocked until that connection is restored. The reply above is pointing the right way, here is the checklist in order of likelihood.
First, is the database actually running. If Postgres is a separate container or service, check it is up (docker ps, or the managed DB’s status). The most common version of this is the DB container restarting or out of disk, and n8n coming up before it is ready. Check disk space on the DB host, a full disk silently takes Postgres down and produces exactly this.
Second, can n8n reach it. If they are separate containers, confirm they are on the same Docker network and the DB host/port env vars in n8n still match. A network or compose change can leave n8n pointing at a host it can no longer resolve.
Third, if the DB is up and reachable but still not ready, check the Postgres logs for connection-limit or recovery messages, a DB stuck in recovery or maxed on connections reports not-ready. Since it started at a specific time (10:05) with no deploy on your side, I would bet on disk space or the DB container restarting first. What changed around 10:05, and is Postgres on the same host or separate?
Check whether Postgres is running and reachable from the n8n container, then disk space, migrations, recent restarts, and the DB connection settings. I would not keep bouncing n8n until you know whether the database is actually down or n8n is pointing at the wrong place. Do you have access to the Docker logs for both n8n and the database?