Why a deploy waits for five clean probes

There is a specific class of deployment bug that is almost impossible to debug after the fact: the deploy reports success, the container is healthy, and yet for about thirty seconds a fraction of requests returned 502. By the time anyone looks, everything is fine.

The cause is usually the gap between a container being ready and the proxy knowing it is ready.

Two different questions

A readiness probe asks the container directly: are you up? That is a useful question, and Railyard asks it. But it is not the question your users are asking. They reach your application through a reverse proxy, which has its own view of which upstream is live, its own configuration reload, and its own moment of convergence.

So a deploy that swaps traffic the instant the container answers is trusting an answer to the wrong question.

What Railyard does instead

After the readiness probe passes, Railyard probes the application the way a browser would — through the real proxy, over real HTTPS, following the same path a user would take. And it requires five consecutive clean responses before the route is moved.

✓ readiness probe passed (2 of 2)
[agent] awaitRouting: 5 clean HTTPS probes
✓ traffic swapped · old container stopped

Three details matter here:

1. Through the proxy, not around it. Probing the container’s port directly would answer the wrong question again.
2. Over HTTPS, not following a redirect. If the probe follows the proxy’s HTTP-to-HTTPS redirect, it can report success against the redirect rather than the application.
3. A streak, not a single success. Convergence is not instantaneous, and a single lucky response proves nothing about the next one.

The payoff

The point of all this is not the deploy itself. It’s that a 502 in your logs now means an actual 502 — something genuinely wrong with the application — rather than a routine artifact of the last release. That makes every error you see afterwards worth investigating, which is the only way error logs stay useful.

Until the swap happens, the previous container is still serving every request. If the probe never goes clean, nothing swaps, the deploy is marked failed with the reason recorded, and your users never knew a deploy was attempted.