Intermittent 5xx errors during Scalingo zero‑downtime deploy despite rolling restart

Question

Goal: achieve zero‑downtime deployments for a small web application on Scalingo by relying on the platform’s rolling restart and predeploy/postdeploy hooks.

Uncertainty: the documentation does not specify whether the router waits for a successful health‑check response (HTTP 200) before routing traffic to a newly started dyno, nor what occurs if the health check fails after the postdeploy hook has run. This ambiguity affects how long‑lived connections are handled and whether in‑flight requests may be dropped during the transition.

Questions:

At what point does Scalingo’s router consider a new web dyno ready to receive traffic?
Does a failing health check after the postdeploy hook prevent traffic routing and trigger a rollback to the previous dyno?
How are long‑lived connections (e.g., WebSockets) treated if the health check is pending or fails during the deploy window?

Tasadduq Burney · Answer

Direct AnswersRouter readiness: Scalingo’s router adds a new web dyno to the load‑balancer pool only after the configured health‑check endpoint returns HTTP 200. The check starts once the dyno process binds to $PORT and repeats at the configured interval (default ~10 s).Failing health check after postdeploy: A failed health check keeps the new dyno out of rotation and marks it unhealthy; it does not trigger an automatic rollback. The previous release continues serving traffic. The deployment eventually times out (default 90 s per dyno) and is marked failed.WebSocket handling: During a rolling restart the old dyno receives SIGTERM, stops accepting new WebSocket upgrades, but keeps existing sockets open until they close or the termination grace period (default 30 s, configurable via termination_grace_period_seconds) expires. Clients must implement reconnection logic; connections are not migrated.Confirmed Behavior vs. Configuration‑Dependent DetailsThe points above reflect Scalingo’s documented platform behavior. However, the exact health‑check path, interval, timeout, and grace period are set per application in scalingo.json or the dashboard. A trivial /health endpoint that returns 200 while the application is still initializing can admit traffic prematurely.Verification Steps for Your AppOpen the Scalingo dashboard → Health Check section (or inspect scalingo.json) and record the exact endpoint, interval, timeout, and termination_grace_period_seconds.Trigger a manual deploy and watch the logs for a line similar to Health check passed, adding dyno to router — this confirms the gating moment.Temporarily make the health endpoint return 500 after postdeploy runs; observe that the new dyno stays in “starting” state while old dynos keep serving.Open a WebSocket connection, initiate a rolling restart, and verify the connection remains alive until the grace period ends or the client reconnects.One Diagnostic Detail NeededWhat is the current termination_grace_period_seconds value in your scalingo.json (or the default if unset)? This determines whether long‑lived HTTP requests and WebSocket frames have enough time to finish before SIGKILL.

Intermittent 5xx errors during Scalingo zero‑downtime deploy despite rolling restart

1 answer

Direct Answers

Confirmed Behavior vs. Configuration‑Dependent Details

Verification Steps for Your App

One Diagnostic Detail Needed

Your perspective belongs here.

0 question comments