On 23 October 2026 Railway published a recovery runbook for customers whose deploys stopped during its security incident. One sentence in it describes a failure mode that is not specific to Railway, and that most teams have never thought about:
"Commits pushed while Railway was not accepting deployments were not queued. Your service keeps running its last successful deployment until you trigger a new one."
That is Railway describing its own recovery, and it is worth reading twice. A deploy freeze is not a delay. Nothing was held back to be released later. The commits you pushed during the pause landed on your branch, your CI went green, and production kept serving the build from before the freeze. There is no error anywhere in that picture. The only sign is a difference between two commit hashes that nobody is comparing.
Railway's runbook lists two more things that made deploys fail after the pause, both consequences of its own credential reset: "GitHub connections were revoked during the incident and must be reconnected before Railway can pull from your repository", and "API tokens and CLI sessions were revoked, so manual deploys from your machine or CI fail until you create new credentials." Those are Railway-specific. The silent drop is not.
Why freezes drop rather than delay
A git push reaches a hosting platform as a webhook: the repository host sends one HTTP request when the push happens. If the platform is not accepting deploys at that moment, whether because of an incident, a maintenance window, a billing hold or a quota block, that request is either refused or never arrives, and the repository host does not keep sending it. GitHub, for example, records each delivery and lets you redeliver it by hand from the repository settings; it does not retry on its own. So we paused deployments almost always means we stopped listening, and a push into silence is simply gone.
The same applies to manual deploys from a laptop or a CI job: a failed deploy command during a freeze is a failed command, not a ticket in a queue.
What this looks like on DeployBase
Since this is a question about platform behaviour, here is ours, read from the code rather than remembered. A push that arrives while another deploy of the same app is still running is chained behind it in the API process, so two quick pushes produce two deploys in order and nothing is lost while that process is up. But a push that arrives while our API is unreachable is not queued either: there is no process that later asks GitHub what it missed. In that case we are the same as Railway. After any outage on our side, the check below applies to apps hosted with us too.
The check, after any freeze
- Find out which commit production is actually running. Your platform's deploy log or dashboard shows the commit it built. Some apps also expose it in a health endpoint or a build-info file. Use whichever is a fact about the running process, not about the repository.
- Compare it with the head of your deploy branch.
git rev-parse origin/mainon your side, against the hash the platform reports. If they match, the backlog did flush. If they differ, nothing will tell you; you have to look. - Trigger a deploy on purpose. An empty commit, a redeploy button or a manual deploy command. Do not wait for the next real push, which might be days away.
- Then confirm the hash again. A deploy that reports success but still shows the old hash has not happened, whatever the status column says.
If you keep a deploy log of your own, record the running hash in it after every incident, maintenance window or billing event on your platform's status page. The habit costs a minute and turns an invisible failure into a line you can read.
Railway's own earlier recommendation, which we covered in Railway's environment-variable breach: could you rotate every secret today?, is the other half of the same lesson: during an incident, the step you can always take is the one that does not depend on the platform resuming.
Source: Railway, "Recover failing deploys", by Mykal Machon, published 23 October 2026 16:30 UTC, read 23 October 2026 at 23:10 UTC. The DeployBase paragraph is from our own deploy code, read the same day.