Hey there! We've found the following might help you get unblocked faster:

• 🧵 getaddrinfo ENOTFOUND

• 🧵 getaddrinfo ENOTFOUND mongodb.railway.internal

• 🧵 error: getaddrinfo ENOTFOUND postgresql.railway.internal

If you find the answer from one of these, please let us know by solving the thread!

hi, intermittent “api unavailable” errors often point to transient infra or networking hiccups inside railway, not necessarily your code. you could try:

‑ retrying failed requests with backoff (e.g. delay + 3 attempts)

‑ switching internal calls to use railway’s private networking (eliminates public egress issues)

‑ monitoring if the failures align with deployments, CI spikes, or infra load

if the issue persists, consider opening a support ticket with timestamps and traceIDs so railway can investigate platform side.

can you check if you enabled the serverless options? that will put your service on stop, also are the metrics ok? do you see any spike in cpu/memory?

Apologies but this looks like an issue with the application level code. Due to volume, we can only answer platform level issues.

I've made this thread public so that the community might be able to help with you query.

thanks for the suggestion ,from where can i raise a ticket ?

You can do so here: (or press N, and then raise a private thread)

Yes, the intermittent availability you're experiencing is caused by Railway's idling policy for services on the Hobby plan. Your diagnosis is correct.

When a service on a free or hobby tier receives no traffic for a period of time, Railway automatically puts it to "sleep" to conserve resources. This process involves stopping your running container and temporarily removing its public DNS record. This is why you see the getaddrinfo ENOTFOUND error in Postman—at that moment, from the internet's perspective, your API's address doesn't exist. When a new request comes in, Railway wakes the service up, which can take a few moments, and the cycle repeats.

## How to Ensure Continuous Availability

There are two primary ways to prevent your service from idling and keep it continuously available.

1. Upgrade to a Paid Plan (Recommended) The official and most reliable solution is to upgrade your account to a paid plan, like the Pro plan. Services on paid plans are not subject to idling and are designed to run 24/7, making them suitable for production applications that require constant uptime.

2. Use an Uptime Monitor (Workaround) A common workaround to keep a Hobby plan service active is to use a free external uptime monitoring service (like UptimeRobot or Better Uptime). You can configure these services to send an HTTP request to your API's health check endpoint every 5-10 minutes. This consistent, low-level traffic tricks the platform into thinking your service is always active, preventing it from going to sleep. While effective, this is a workaround, and upgrading is the intended path for production services.

That's not true!!

Only "serverless" services deployed on Railway would sleep after 10 minutes of inactivity (which includes nothing being received/sent to the service). Please read about that in the docs: https://docs.railway.com/reference/app-sleeping

This thing was previously known as app sleeping, and is not what regular deployments would follow. Please don't post anything which is irrelevant to the query!