Railway is a hosting platform that deploys containers from a Git branch and bills by the second for CPU and memory. A new workspace starts on a trial: a one-time $5 credit that lasts 30 days, after which you pick Hobby at $5 a month or Pro at $20, each with a matching usage credit (railway.com/pricing). Credits carry over only if you upgrade. We did not.
What we saw
On 2026-10-07, while chasing a Neon bill, we opened the Railway dashboard to deploy the fix. It would not deploy. The banner read:
“Your trial is over. All deployments are paused. Unpaid invoice. Your card number is incorrect.”Railway dashboard, 2026-10-07
Six projects sat behind that banner: a CRM backend that answers phone lines for doctor's offices, a front-desk product, the database side of a client's storefront, and three internal services. The containers from August were still running. Nothing new could ship.
What was actually happening
The card and the invoice were the visible failure, and they were the smaller one. The CRM repository's CI had been red since 2026-09-23 on lint errors that nobody treated as urgent. Railway waits for CI before it deploys. So for 14 days, every merge to main was accepted, every deploy was skipped, and the production container stayed on 2026-09-24's code. The trial expired underneath that silence.
By 2026-10-08, main was 321 hours ahead of what was running. The pull request that would have cut our Neon churn merged that night and joined the queue behind a card number. The fix for one bill was stuck behind another bill.
Railway's own docs describe the trial as 30 days or the credit, whichever ends first, and say deployments pause when a workspace has no valid plan (Railway docs: free trial). None of that is hidden. It is simply not the kind of thing a team notices while the old container keeps answering requests.
What we changed
The payment side is a human task, and only the account owner can do it, so that stayed open on 2026-10-09 while this was written. What we could change, we did. The vendor board grew a deploy signal for Railway: it reads each project's latest deployment, compares it to the newest commit on main, and alerts when production is more than a few hours behind. On its first run it reported 321 hours. That number, not the banner, is what would have caught this on day one.
The Neon fix moved out of the deploy queue entirely. We applied the same rule as a database trigger, measured 0 writes a minute where there had been 251, and left the code change to ship whenever Railway resumes. The trigger is one DROP statement to remove.
Two rules were written down for the rebuild. Red CI blocks merges, so a skipped deploy cannot hide behind an accepted pull request. And production never runs on a trial workspace, because a trial's only exit is a card on file, and a card is a single point of failure. Railway's plan page lists the Hobby and Pro tiers that a production workspace should sit on from the first day (Railway docs: plans).
What a monitor should have said
Not the banner. The banner arrived last. The useful alert is the drift between the branch and the box, and it is available from the platform's API long before any invoice is late.
“Railway crm-block-theory-backend: no deployment for main since 2026-10-08 (321 h behind)”Mepa8 alert, 2026-10-08
Mepa8 raises that line at a warning after 6 hours and critical after 24. It also raises the plain one, trial expired and deployments paused, as critical with the action attached: pay the invoice or pick a plan.
The lesson
A deploy that silently does nothing is more dangerous than one that fails, because a failure makes noise and a skip makes none. Measure the distance between main and production the way you measure a bill, as a number with a threshold, and alert on it. Keep a second payment method on every platform that can pause you. And never let a product that answers someone's phone depend on a trial. See the Railway vendor page for the signals Mepa8 reads.
Questions people ask
Why did nobody notice for 14 days?
Because the August container kept serving traffic, so every health check passed. CI went red on lint errors on 2026-09-23, Railway skipped each deploy that followed, and no system compared main to production. The first number that said something was wrong was 321 hours of drift.
Did the paused deployments take anything down?
No. Railway kept the existing containers running; it stopped new ones. The cost was stale code: a merged Neon fix could not ship, and the CRM backend for a doctor's office stayed on 2026-09-24's build until the account owner fixed the card.
What does Mepa8 watch on Railway now?
Three things: the workspace's plan and invoice status, each project's latest deployment status and date, and the gap in hours between the newest commit on main and the running build, with a warning at 6 hours and a critical alert at 24.
Sources
- Railway pricing — trial $5 one-time credit for 30 days, Hobby $5 with $5 credit, Pro $20 with $20 credit; fetched 2026-10-09
- Railway docs: free trial — trial length and what pauses
- Railway docs: plans — Hobby and Pro tiers
- Mepa8 vendor page: Railway — what the monitor reads
Change log: October 9, 2026 — First published. Numbers are from our own accounts and logs.