7 days ago
Hello Railway Central Station Support,
We need help investigating a reproducible Railway healthcheck/routing failure in staging.
Project details
- Project: umbra-automation-clinic
- Project ID: 1e174329-ab99-433d-8e5c-10a1593dbedb
- Environment: staging
- Environment ID: f25de876-ceac-4b1f-a59d-f0959d8499b8
- Service: frontend
- Service ID: d4f17def-c703-46ba-aa3d-bd1bd870a27c
- Deployment ID: ae156dfc-4aa7-4c33-bafc-25c1801af42f
- Git commit: 350199d7f6d20d4eb8902c724b0cd1a820597856
- Region: europe-west4-drams3a
- Deployment timestamp: 2026-08-14 17:07 GMT+2
Configuration
- Dockerfile: frontend/Dockerfile
- Application port: 3000
- PORT is explicitly configured as 3000, and the process confirms that it is listening on 0.0.0.0:3000.
- Healthcheck path: /healthz
- Healthcheck timeout: 300 seconds
- Replicas: 1
- The required Cloudflare Access configuration variables are present; their values are intentionally omitted.
- The development bypass variable is not present.
Observed behavior
- The Docker build completed successfully and the image was exported successfully.
- Deploy logs show Next.js 16.2.12 advertising both http://localhost:3000 and http://0.0.0.0:3000, then Ready in 0ms.
- No runtime exception or process exit is visible in the deployment logs.
- Railway repeatedly attempted the healthcheck throughout the configured 300-second window.
- Every visible attempt was reported only as “failed with service unavailable”.
- Railway finally reported “1/1 replicas never became healthy!” and “Healthcheck failed!”.
- The deployment failed during the network phase.
- Network Logs display “No logs in this time range”.
- Railway exposes no HTTP response status for these attempts, so this report does not assert that Railway received any particular HTTP status.
- No X-Railway-Request-Id or other internal request/trace identifier is shown.
Status page
Railway’s public status page did not show a widespread incident, but it states that smaller or isolated issues may not appear there.
Related Central Station review
- A solved thread attributed a similar symptom to a missing PORT setting; that does not match this deployment because PORT is explicitly set to 3000 and the process confirms the expected binding.
- A solved intermittent-healthcheck thread involved an application-side HTTPS redirect; that differs from this reproduction.
- A current thread describes a broadly similar symptom in us-west2, but it has no official resolution and is in a different region.
Local reproduction evidence
The exact merged commit, unchanged frontend Dockerfile, build argument, and Railway-equivalent runtime configuration were reproduced locally. GET /healthz returned HTTP 200 with the expected generic response through a localhost-bound mapped port, with Host: healthcheck.railway.app, and from inside the container on 127.0.0.1:3000. The Dockerfile HEALTHCHECK reached healthy, the process bound to 0.0.0.0:3000, and no runtime errors occurred.
Questions
- Did Railway’s internal healthcheck request reach this container?
- If it did not, why did routing or service registration fail before an HTTP response was available?
- Can Railway provide the internal request or trace identifiers for these healthcheck attempts?
- Are internal healthcheck requests expected to appear in Network Logs? If so, why are no entries available for this deployment?
- Was there a platform or regional issue affecting europe-west4-drams3a at the deployment timestamp?
- Are there internal routing, port-detection, or healthcheck diagnostics for this deployment that explain the generic “service unavailable” result?
Attachments
- Failed deployment status
- Healthcheck configuration showing /healthz and 300 seconds
- Build logs
- Deploy logs
- Full healthcheck output
- Evidence that Network Logs were empty
No secrets, tokens, complete environment-variable values, email addresses, patient data, or other real data are included.
3 Replies
7 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 7 days ago
7 days ago
Can you check your Deploy Logs and confirm if the app is actually starting?
If there's no Application starting logs, Try set custom start command on the service settings
7 days ago
Do you have middleware (proxy) set up in your next.js app? If so, exclude /healthz from the middleware config matcher.
7 days ago
Thank you both.
The application is definitely starting successfully. The Deploy Logs show:
- Next.js 16.2.12
- Local: http://localhost:3000
- Network: http://0.0.0.0:3000
- Ready in 0ms
There is no subsequent runtime exception, process exit, restart, or shutdown message. Railway starts the healthcheck while the application process remains running, so we have not added a custom start-command override.
The application does use a Next.js proxy. /healthz is not removed from the matcher entirely; instead, the proxy immediately bypasses all Cloudflare Access authentication for that exact pathname before any JWT verification, JWKS request, or backend request occurs.
That exact production path was tested with an image built from the same commit and unchanged Dockerfile. With the required runtime configuration present, /healthz returned HTTP 200:
- through the mapped host port,
- from inside the container through
127.0.0.1:3000, - with
Host: healthcheck.railway.app.
The Dockerfile HEALTHCHECK against the same endpoint also became healthy. The required Railway runtime configuration was independently confirmed as present without exposing its values.
For comparison, another Next.js service in the same Railway usage context passes its Railway healthcheck with a matching Railway runtime port and public target port.
The unresolved question is therefore whether Railway’s healthchecker connected to this deployment’s replica on port 3000 at all. Railway exposes no HTTP status or request/trace ID, and Network Logs contain no entry for the failed healthcheck window.
Could you please help verify which effective PORT, target port, and replica address Railway used for deployment ae156dfc-4aa7-4c33-bafc-25c1801af42f, and whether the failure occurred before or after establishing a TCP connection?