Your custom domain api.margotmercury.com has a stale CNAME - it currently points to 1ro3dre4.up.railway.app (the old, deleted service's target) but the recreated service expects ims114lf.up.railway.app. Update the CNAME record at your DNS provider to the new target value. The generated service domain's TLS certificate has also failed to issue, which should resolve once a deployment succeeds after the CNAME update and the routing re-establishes.

Following up on my post above.

I applied the CNAME fix you suggested — api now points to ims114lf.up.railway.app (confirmed via dig api.margotmercury.com CNAME +short), and the Networking tab now shows api.margotmercury.com as verified (green check). So that half is resolved.

But the service is still down, and it's not a DNS/domain issue anymore — it's failing healthcheck on every deploy:

Build: succeeded (9s)

Deploy: succeeded (7s)

Network > Healthcheck: failed after ~92s (healthcheckTimeout is set to 100s in railway.json)

Deploy logs show the app starting cleanly and completely before the healthcheck window even ends — Nest finishes bootstrapping, every route including GET /health is mapped, and api listening on :3001 prints, all within a couple seconds of container start. There's no error, crash, or exception anywhere in the logs. The process is just up, listening on the correct port, healthy — and the healthcheck still times out ~92s later.

I also tried the "Diagnose" button on the failed deployment. It returned: "Diagnosis failed for this deployment." No further detail.

So at this point:

The container is confirmed running and listening on the port configured in Networking (3001).

/health is confirmed mapped and returns a trivial {status: 'ok'} with no external dependencies in the handler itself.

The healthcheck still fails, timing out rather than getting a fast error response — which reads like the prober isn't reaching the container at all, the same symptom as the edge-routing issue from my first post, just one layer earlier in the pipeline.

Your own automated diagnosis tool fails to produce a result on this deployment too.

I've exhausted what I can debug from my side — app code, Dockerfile, env vars, and DNS have all been checked and ruled out. Could someone on the team take a direct look at project elegant-cat (70c94c46-d01e-4f7e-941b-556bbf868544), service kindry-2026? At this point I think this needs a human looking at the platform side rather than more changes on mine.

Thanks,

Thomas

The edge still has no traffic routes installed for either domain (x-railway-fallback: true on both), which is why healthchecks time out - the prober reaches the edge but the edge has no path to the container. This matches a known migration requirement: private networking must be enabled on the service for routing to work. In the service's Settings under Networking, enable Private Networking, then redeploy. That should re-establish the routes and resolve both the healthcheck failures and the service domain's certificate.

I'd try removing the domain from Railway and adding it back after ~10-15 mins. Update DNS records as necessary.

Also, try disabling the healthcheck for now and see if the application starts.