For most of Wednesday, October 21, Railway’s customers were looking at what seemed to be a bad outage: no dashboard, no new builds, and a support site that would not load. Only that evening did the status page link a security notice saying an unauthorized third party may have reached customers’ encrypted environment variables. This railway breach timeline puts every public update in order, with each time in UTC as Railway posted it and in U.S. Eastern time.
Where it stands: The newest update we found went up at 01:22 UTC on October 22, which was 9:22 p.m. Eastern the previous evening. It listed Railway’s remediation guides and said they “may require redeployment of services which you will not be able to complete until Builds are available again. However, there are steps you may begin to take.” Nothing newer had appeared when we re-checked the page at 01:49 UTC (9:49 p.m. Eastern), and builds were still paused. Railway’s notice tells users to “Follow this incident to be notified when builds resume.”
The railway breach timeline at a glance
| UTC | ET | What Railway posted |
|---|---|---|
| Oct 21, 07:24 | 3:24 a.m. | Outage incident opened |
| 08:28 | 4:28 a.m. | Backend issues seen |
| 09:28 | 5:28 a.m. | No dashboard, API or CLI; builds paused |
| 11:33 | 7:33 a.m. | API back, partly |
| 16:29 | 12:29 p.m. | Support site unavailable |
| 19:15 | 3:15 p.m. | Staged return of builds announced |
| 19:30 | 3:30 p.m. | Enterprise builds expected by 20:30 UTC |
| 20:19 | 4:19 p.m. | OAuth sessions invalidated |
| 21:01 | 5:01 p.m. | No new build information |
| 21:59 | 5:59 p.m. | Notice on env vars linked |
| 22:10 | 6:10 p.m. | Bucket credentials rotated |
| 22:45 | 6:45 p.m. | Staff resets in audit logs explained |
| Oct 22, 00:22 | 8:22 p.m. (Oct 21) | Guides promised |
| Oct 22, 01:22 | 9:22 p.m. (Oct 21) | 13 guides published; builds still down |
The incident on status.railway.com is still headed “Railway Platform Outage Major Outage.” Its title never changed to name a security event, even after the notice was linked.
Before dawn in New York: an outage with no stated cause
The first entry is a single line: “We are currently investigating this issue October 21, 07:24 UTC.” That is 3:24 a.m. on the U.S. East Coast. An hour later, at 08:28 UTC, Railway added: “We are seeing issues on Railways backend as well. We are still investigating this issue.”
By 09:28 UTC (5:28 a.m. Eastern) the incident had moved to “identified,” and the scope was large: “the Railway dashboard, API and CLI are unavailable, and new builds remain paused in all regions.” The same entry warned: “Our support site is also affected, so replies to support requests will be delayed.”
At 11:33 UTC (7:33 a.m. Eastern) there was partial relief: “Builds remain paused. Our API is back up, but some features remain unavailable.” None of these morning updates mentioned a security problem.
Through the afternoon: paused builds, no support desk
For the next several hours the updates mostly repeated themselves. At 16:29 UTC (12:29 p.m. Eastern), Railway wrote that builds and deployments were still paused and that “our support site (station.railway.com) is also unavailable, so new support requests cannot be submitted there at this time.”
Later entries settled into a rhythm of check-ins promised at least every half hour. The 17:45 UTC entry (1:45 p.m. Eastern) opened with: “There is no change to report.” For a developer trying to ship a fix, the practical picture all afternoon was the same: no new builds and no new deployments.
Early evening: a plan to bring builds back in stages
At 19:15 UTC (3:15 p.m. Eastern), Railway set out an order of return: “Enterprise workspaces first, followed by Pro, then Hobby, then Free and Trial.” At 19:30 UTC (3:30 p.m. Eastern) it described the cause only in general terms (“Earlier today an issue affecting multiple systems led us to pause builds across the platform”) and gave a target: “We expect builds for Enterprise workspaces to be available by 20:30 UTC.”
The 20:19 UTC entry (4:19 p.m. Eastern) brought a step some users would have felt directly: “Due to impact from adjacent cache systems, we are invalidating OAuth sessions as part of our mitigation. Affected users will be signed out and will need to log in again.”
At 20:35 UTC Railway said it was “validating builds for Enterprise workspaces and should be re-enabling for Enterprises broadly very soon.” The 20:30 UTC target passed without a confirmed restart. At 21:01 UTC (5:01 p.m. Eastern), the update was: “We do not yet have additional information to provide about the availability of builds.”
21:59 UTC: the outage becomes a security incident
At 21:59 UTC (5:59 p.m. Eastern), the status page changed character. “We have published a security notice covering what we know so far and the actions we recommend you take,” it began, linking to a blog post by Jacob Cooper.
That post said: “Earlier this morning, Railway detected anomalous activity involving systems that store customer environment variables.” It went on to say that “an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents.” The status entry added that “Deployments remain paused while we investigate, including for Enterprise customers,” and that affected customers would be contacted by email once confirmed. What the notice means for users is covered in our Railway security incident explainer.
Railway has not said at what point it concluded that the outage was a security event. The blog’s “earlier this morning” does not name a time zone or an hour, so the gap between first detection and public disclosure cannot be measured from what has been published.
Late evening: Railway rotates what it can
At 22:10 UTC (6:10 p.m. Eastern), Railway began resetting one class of secret itself: “We are rotating all Railway bucket credentials in response to the security incident. New credentials will appear in your dashboard automatically.” Services could not yet pick them up, since builds were still frozen. At 22:37 UTC the message was brief: “Builds remain paused. We will post here as soon as they resume.”
The 22:45 UTC update (6:45 p.m. Eastern) answered a question users were likely to raise when they saw unfamiliar entries in their logs. Railway said customers might see revocations by a named employee, Faraz Patankar, and that “This is expected, as we previously indicated, we are revoking all existing storage bucket credentials out of an abundance of caution.” A later guide identified him as part of “Railway’s engineering team” and said the events carry the actor type “Railway Staff.”
After midnight UTC: the guides arrive
At 00:22 UTC on October 22 (8:22 p.m. Eastern on the 21st), Railway said it “will be publishing guides shortly to help users through recommended next steps regarding the security notice.”
An hour later, at 01:22 UTC, it posted links to 13 guides, all bylined Mykal Machon: checks for unexpected usage at OpenRouter, Grok, Anthropic, OpenAI and Stripe; checks for anomalous GitHub, AWS and Google Cloud access; credential rotation for PostgreSQL, MySQL, Redis and MongoDB; and a guide to redeploying buckets and reconnecting GitHub after Railway’s reset. The guides describe themselves as part of “Railway’s response to the security disclosure published on October 21, 2026.” The order in which to work through them is laid out in our Railway secrets rotation checklist.
Outside coverage was thin on the first night. Techmeme ran the story under the headline “Cloud provider Railway says an unauthorized party may have accessed customer encrypted environment variables and, for some, obtained the decrypted contents,” and listed only one other outlet, The Defiant, alongside it.
The guides carry an October 22 date on Railway’s blog because the company works in UTC. On the U.S. East Coast, the list of 13 was live by 9:22 p.m. on October 21.
Frequently Asked Questions
When did the Railway breach start?
Railway has not said when the intrusion began. Its status page opened an outage incident at 07:24 UTC on October 21 (3:24 a.m. Eastern), and its security notice said the company detected the anomalous activity “earlier this morning.” The notice reached the status page at 21:59 UTC (5:59 p.m. Eastern).
Are Railway builds back up?
No. At our last check (01:49 UTC on October 22, or 9:49 p.m. Eastern the night before), the most recent entry was the 01:22 UTC guide list, which said Railway would update once builds were available. Railway said builds would come back in stages, Enterprise workspaces first.
Why was I signed out of Railway?
At 20:19 UTC on October 21, Railway said it was invalidating OAuth sessions because of impact from adjacent cache systems, and that affected users would need to log in again.
Who is Faraz Patankar in my Railway audit log?
Railway says Faraz Patankar is on its engineering team and performed the storage bucket credential resets. Railway says those entries are expected and show the actor type Railway Staff.
Sources
- Railway Platform Outage — Railway status page, October 21-22, 2026 (live page, checked October 22, 01:49 UTC)
- Security Disclosure: Wednesday October 21st — Railway (Jacob Cooper), October 21, 2026
- Security Disclosure Recommendation: Redeploy Buckets and Reconnect GitHub After the Credential Reset — Railway (Mykal Machon), October 22, 2026
- Cloud provider Railway says an unauthorized party may have accessed customer encrypted environment variables — Techmeme, October 21, 2026
This article is news reporting and general security information based on the public sources listed above, as they stood on the dates shown. Incident details often change as investigations continue; check the affected company’s own status page and notices for the latest. Data Breach Radar is not affiliated with any company named here.