Application failed to respond

Your "racketControl" service shows a successful deployment status, but it is producing zero runtime logs, which means your application process is likely crashing immediately on startup before it can bind to a port. This is what causes the "Application failed to respond" error. Check your deploy logs in the Railway dashboard for your latest deployment to see if there are build-time or startup errors, and verify that your app is binding to 0.0.0.0 on the PORT environment variable as described in our troubleshooting guide.

No, the application works. But recently started failing on startup.

Your service has Serverless (app sleeping) enabled, and the logs show it being stopped due to inactivity and then restarted when a request comes in. Your Spring Boot application has a cold boot time during which the first request that wakes the service times out, resulting in the "Application failed to respond" error. You can disable Serverless in your service settings to keep the service running continuously, or the first request after a sleep period will need to wait for the full application startup.

Thank you for the explanation. However, this is not an issue with my application.

Previously, when Serverless (app sleeping) was enabled, the first request would wait for the cold start and complete successfully. Now, with the same setup, the first request immediately fails if the app is sleeping.

This behavior change is on Railway’s side, as there is nothing in my Spring Boot application that can make the request wait while the container starts. The request never reaches my app until the container is fully up, so the timeout occurs before any application code runs.

Please confirm whether this change in Serverless behavior is intentional, and if there is any way to restore the previous behavior where the first request would wait for the cold start.

Thank you.

Hey there,

Your Public domain appears to be misconfigured, which is causing requests to racketcontrol.me to fail. I was able to hit the public endpoint of your generated domain just fine.

You'll need to configure your DNS correctly for this issue to be resolved. Check out the docs: https://docs.railway.com/networking/domains/working-with-domains#custom-domains

Hi,

I want to clarify that the issue I’m experiencing is not related to DNS. The problem occurs with Serverless (app sleeping) where the first request after a sleep fails immediately. Previously, with the same setup, the first request would wait for the app to start and complete successfully.

This behavior has changed on Railway’s side. There is nothing in my Spring Boot application that can make the request wait while the container boots, because the request never reaches my app until the container is fully up.

Therefore, this is a platform-side issue with Serverless and not a misconfiguration on my end. I would appreciate confirmation whether this change in behavior is intentional, and if there is any way to restore the previous behavior.

Thank you for your attention.

The problem is related to https://racketcontrol-production.up.railway.app

if it was working before and nothing changed in your code, a few things to check:

your deploy might be hitting the memory limit on Hobby. go to Metrics tab and see if memory spikes right before the crash.

Railway kills the process if it exceeds the limit and you get zero logs because it dies before writing anything. also check if your build recently switched to a different Nixpacks version or runtime. Railway updates these automatically and sometimes a new base image breaks stuff. you can pin the runtime version in a nixpacks.toml or Dockerfile to rule that out.

try redeploying from the same commit that was working before, if that also fails then it's definitely something on the infra side, not your code

The issue only happens during the cold start, so this is definitely a serverless problem. It is not a memory issue because I’m never close to even half the limit. The app works fine once it’s warm, which points to initialization delays or timeouts on the first request after being idle.

I added the memory logs. No, i never reached the limit (4 CPU/4GB)