Does Railway switch traffic before or after a deployment's health check passes?

Direct Answer

Railway switches traffic to a new deployment only after its health check passes. The previous deployment continues serving all requests until the new one reports healthy. If the health check fails (exceeds the configured failure threshold), the new deployment is marked failed and never receives traffic; rollback is effectively invisible to end users.

Confirmed Behavior

• Promotion is gated by health checks. The service URL alias points to the new deployment only after the health check succeeds.
• Failure threshold defaults to 3 consecutive failed checks. A single failed check does not trigger rollback unless you set the threshold to 1.
• Configurable parameters per service: HTTP path, port, initial delay, check interval, timeout, and failure threshold.
• No native canary or blue-green shifting. Cutover is atomic after the new deployment reports healthy.

Plan Differences and Defaults

Health check customization is available on all paid plans. The free tier may enforce stricter defaults (shorter timeouts, lower thresholds) — verify in your project's Settings → Health Checks. If no health check is configured, Railway treats the deployment as healthy immediately after the process starts, switching traffic without waiting for application readiness.

Practical Implications

• Set the failure threshold to 1 only if you want the fastest possible rollback; higher thresholds (default 3) tolerate transient blips.
• Choose a health check path that reflects true readiness (e.g., a DB connection test), not just process liveness.
• Ensure database migrations are backward-compatible with the previous deployment, because the old version stays live until the new one passes.
• External uptime monitors are redundant for Railway-managed traffic but useful for cross-platform observability.

Verification Steps

1. Open the service in the Railway dashboard → Settings → Health Checks to view current path, port, interval, timeout, and failure threshold.
2. Trigger a test deployment with an intentionally failing health check path (e.g., a non-existent route). Observe in deployment logs that the service URL continues returning responses from the previous deployment.
3. Check the Railway changelog or docs (docs.railway.app) for recent updates to "Deployments → Health Checks" or "Rollbacks".

One Diagnostic Detail Needed

What is your current plan (Free, Hobby, Pro, or Enterprise)? Free-tier defaults may shorten the effective window before rollback, which changes how conservative your timeout and threshold settings should be.