Please try this if it helps:

These are actually two different failures — separating them is the key.

Attempts 1–3 (stuck at Created, zero logs, flat 0 metrics) = platform-side, not your code. No logs + no CPU/mem/network means the container never started — your process never ran, so there's nothing in your code to fix here. The unchanged commit that ran for weeks, plus attempt 3 self-dropping with a new instance ID and no trigger, both point to the orchestrator cycling a wedged deploy. Escalate this to Railway with your deploy IDs. Quick isolation test: redeploy to a non-sfo region and see if the Created symptom vanishes.

Attempt 4 (process runs ~200MB, but every request incl. /health hangs then fails) = app-side, and fixable. The jump to sustained memory means it started this time. "Hangs then fails" (not fail-fast) is the classic sign of a process blocking on a startup dependency it can't reach — a DB/Redis connection that's instant locally but hangs over Railway's private network. Check:

Anything await-ing a DB/cache connection before app.listen()? Bind the server first, connect lazily.

Does /health touch the DB? Make it a static 200 that touches nothing — if it then responds instantly while other routes hang, that isolates the culprit.

Verify any *.railway.internal hostnames the app dials.

The "bind first, connect lazily" pattern:

"

jsconst app = express();

// Health check touches nothing — always answers instantly

app.get("/health", (_req, res) => res.sendStatus(200));

app.use(routes);

// Bind FIRST so the platform sees a ready server immediately

app.listen(process.env.PORT, "0.0.0.0", () => {

console.log("listening on", process.env.PORT);

});

// Connect to dependencies AFTER, without blocking startup

initDb().catch((err) => console.error("db connect failed:", err));

"

If your DB/Redis connect is await-ed before listen(), a dependency that hangs takes the whole server down with it — exactly your attempt-4 symptom. Binding first means the process is reachable the moment it starts; a hanging dependency then fails loudly in logs instead of silently wedging the deploy.

TL;DR: escalate 1–3 to Railway (platform-side, nothing to fix in your code), and for attempt 4, decouple binding + /health from your dependencies.

@hygrivakondury: Per your earlier note, we fixed our app to bind explicitly to 0.0.0.0 instead of the Node default dual-stack ::, since that matched the "stuck at Created, zero logs, flapping 502s" symptom on attempts 1-3. That fix deployed at 00:54:58Z yesterday. It didn't help — the exact same reachability symptom continued on the new deployment for the next ~12 hours, then cleared on its own with no restart, redeploy, or code change on our end. This points to a proxy/networking issue on your side in the sfo region for this project, not our application.

Evidence:

• Same instance (7f6ea3ad...) ran continuously the whole window — no crash, no restart, no OOM, no new deployment. Console logs show only the normal startup line (Starting Container → Vern listening on port 8080) once, at deploy time.
• HTTP logs from 00:56:26Z to 13:02:01Z (today): of 58 requests to /health (a static handler — no DB, no dependencies, res.json({status:'ok'})), 49 returned 499 (client/proxy gave up after ~7.9s) and 5 returned 502 (hard 15s timeout). Only 4 succeeded, all after 13:09:16Z.
• Zero non-health requests logged in that entire 12-hour window — no inbound webhook traffic reached the app at all (or reached it and never got logged), which is itself notable for a service that normally receives regular webhook calls.
• Recovery at 13:09:16Z was not caused by anything on our side — we checked our scheduled jobs (GitHub Actions) and confirmed nothing fired in that window; the service just started responding in single-digit milliseconds again with no intervention.

1. Can you check proxy/edge reachability logs for this deployment/instance in sfo between 2026-07-14T00:54Z and 13:09Z? We'd like to know what changed at 13:09Z that fixed it.
2. Is this a known recurring issue for the sfo region? If so, would redeploying to a different region avoid it going forward, or is this project-specific?
3. Given the app was unreachable for ~12 hours despite a healthy, running process, is there anything about this service's health-check or proxy configuration you'd recommend changing on our end?