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

Ordering between traffic switching and rollback

Railway documents two behaviors that appear to interact: every successful deployment receives a permanent URL alias routing traffic to the current version, and a service rolls back to the previous deployment when a new one fails its health check. What the documentation leaves open is the ordering of those events during a risky deploy.

The goal is to reason about user-visible impact before configuring health checks for a web service. If the alias only switches after the new deployment reports healthy, a failing build never serves traffic and rollback is invisible to users. If the alias switches first and reverts on failure, there is a window in which requests reach an unhealthy deployment.

The distinction affects how conservative health check settings should be — path, timeout, retry counts — and whether an external readiness probe is still needed. Behavior may also vary across subscription tiers and could shift with platform updates, so current documentation should be confirmed rather than assumed.

Open questions

• Does Railway wait for health checks to pass before pointing the service URL at a new deployment, or does it cut over immediately and revert on failure?
• Is rollback triggered by a single failed check or by a configurable failure threshold?
• Which health check parameters are configurable per service, and do they differ by plan?