I have a self-hosted n8n installation on a Hostinger VPS using Docker. I’m experiencing recurring database-not-ready/503 errors and workflow execution failures. I need someone to diagnose the server, Docker containers, n8n database, logs, and workflows without unnecessarily modifying the existing workflows.
Hey @Shivani_Jadhav, while you wait for a response, here are some things that might help:
Suggested resources
Automatically matched to your question.
Docs:
Forum:
@Danilov_Vovka, @daniel_Samuel, @Byte_Nova - you’ve helped with similar issues before, can you take a look?
Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.
Hi @Shivani_Jadhav, I wouldn’t change the workflows yet. Database is not ready! means n8n has lost its database connection, but the 503 alone doesn’t say why.
Right after the next 503, before restarting, please share docker ps -a and docker logs --timestamps --since 10m <n8n-container>. If PostgreSQL runs in another container, share its logs from the same time. Which n8n version and database type (SQLite or PostgreSQL) are you using? Do the workflow failures happen at the same time?
Please redact passwords and tokens, and don’t post VPS access here.
Hi Shivani, when the 503 clears, does a new workflow execution succeed, or is only the editor available again?
I’d track one incident with three timestamps: the first 503, when the editor becomes reachable, and when the next execution actually succeeds. Match those against the n8n and database logs. That helps separate a brief availability problem from a system that looks recovered but still can’t run the work.
For a failed execution from that window, please include the node name and exact error. A 503 from an external API and a database error need different fixes, even if they appeared at the same time. Remove credentials and customer data before sharing anything.
After a change, I’d verify both a representative workflow and the workflow that failed during the incident—not just whether the login page loads.
When this happens on your VPS, does it recover on its own, or only after you restart something?
A few of these can be separated before anyone touches a workflow, and all of it is read only.
Tell a restart loop apart from a real database fault first. On a VPS, “Database is not ready!” plus a 503
at the proxy is very often n8n being OOM killed and restarted, not the database failing. Every request
inside that restart window gets exactly that error, so it reads like a database problem when it is
actually memory.
docker inspect --format ‘{{.State.OOMKilled}} {{.RestartCount}}’
If RestartCount goes up by one with each 503 you saw, it is a restart loop. docker events --since 15m is
the quickest way to see which container actually died, because it timestamps the die, restart and
health_status events for both containers in one stream, which the logs on their own will not tell you.
If it happens on every boot rather than at random, it is startup order. depends_on on its own only waits
for the container to exist, not for Postgres to start accepting connections. Without a pg_isready
healthcheck on the database and condition: service_healthy on n8n, n8n comes up first and logs “Database
is not ready” on every single start.
Check the disk before anything clever. df -h and docker system df. Postgres stops accepting writes when
the volume fills, and on a small VPS the thing that fills it is usually execution data. That one looks
intermittent and appears to clear up for a while after a restart, which is what makes it confusing.
The workflow failures may well be a separate question, and it is worth splitting them off. Two different
things look identical in the UI: an upstream API returning “Service unavailable, try again later”, which
is transient and is cured by turning Retry On Fail on, and a credential that has actually died, which
shows invalid_grant or a 401 and will never succeed on a retry. n8n nodes ship with retry off, so the
transient ones fail when they did not need to. Worth knowing which of the two you have before blaming
the server.
For the real per-node error rather than the summary: GET /api/v1/executions?workflowId=&limit=5, then
GET /api/v1/executions/?includeData=true. One thing that cost me time there: if the
execution ids jump (4012 then 4015) with nothing listed in between, those runs are usually stuck in
status “running”, and the filtered list leaves them out, so they look like they never happened at all.
Hi @Shivani_Jadhav — Anshul’s request for logs around the same failure is the right starting point. One additional check: n8n uses SQLite by default, so confirm DB_TYPE rather than assuming a PostgreSQL container. For PostgreSQL, compare the database host with your Compose service name; localhost inside the n8n container refers to that container. Do not change configuration until the topology is clear. The Database documentation linked by the community bot lists the relevant settings.
If you want paid assistance, I can offer a US$150 read-only review of one failure window: redacted n8n/database logs, version, database type and redacted Compose configuration. Deliverable: a timestamped trace, findings tied to evidence, and a proposed fix/verification plan, with unknowns marked. No VPS access, production changes or workflow edits; no guaranteed restoration. My verified work is local n8n intake testing, not a production Hostinger case study. We’d agree materials, acceptance checks, delivery time and PayPal payment terms before starting. Would this limited review fit, or are you seeking only community troubleshooting?
Hi Shivani, one check before touching anything: if this is the default SQLite setup, look at the size of database.sqlite and at free disk space (df -h). n8n prunes old executions by default, but SQLite never hands the freed space back to the disk unless DB_SQLITE_VACUUM_ON_STARTUP=true is set (or VACUUM is run once). A multi-GB database on a nearly full VPS disk is a common cause of slow starts and “Database is not ready”.
If you’d like it done for you: fixed price 99 €, read-only first via a temporary SSH key you revoke afterwards, a written root-cause report, changes only after your OK, workflows untouched.
How large is your .n8n folder right now (du -sh)?
Maxi (Määäx)
Hi @Shivani_Jadhav, is this issue still unresolved? Are you looking for paid troubleshooting, or community help only? I have website backend project experience, but no completed Hostinger/n8n production recovery case, so I would first assess redacted logs and the scope before proposing any work. If paid help is an option, could you share your budget and what a successful diagnosis should include? Please do not post credentials or customer data.