Railway’s November outage. What to check first.

What Railway reported

The 4 November notice at 18:54 UTC described external blocks affecting Railway access after a third party forged Railway source IPs in scanning traffic. The 22:03 UTC update remained Identified, with no restoration estimate. Railway reported no evidence connecting this to October’s security incident. Those updates correspond to 21:54 on 4 November and 01:03 on 5 November in Riyadh. Status checked on 5 November.

Build a small evidence sheet before changing anything

Our recommendation is to record the exact hostname, time and time zone, connection used and visible failure. Distinguish a browser warning, a connection timeout, a certificate error and an HTTP response from your application. Keep a screenshot or a sanitized error message. This gives the person handling the incident something reproducible and helps avoid unrelated configuration changes while the failure is still being understood.

• Record whether the issue affects the whole application or one route.
• Separate confirmed failures from customer reports awaiting reproduction.
• Remove tokens, cookies and personal data before sharing diagnostics.

Compare access from the networks your customers use

Test the same harmless, read-only page over two independent connections, such as office Wi-Fi and mobile data. Keep the device, URL and test time as consistent as possible. For a Saudi-facing service, include a connection representative of your actual users. Record success as carefully as failure. If one path works and another fails, send that comparison to the network administrator or provider handling the affected connection. Repeat only enough to establish the pattern.

Check the hostname and the application independently

Railway’s public networking supports both provider domains and custom domains. For your own service, compare the configured public hostname with the customer-facing hostname, where your application permits this. Confirm that the DNS records and certificate match the intended setup. A comparison helps narrow the investigation, but both names may share infrastructure. Treat any hostname change as a planned application change, especially where authentication callbacks, cookies or external integrations depend on it.

Keep monitoring after a successful deployment

Railway documents that its configured healthcheck gates deployment activation and is not continuous monitoring after the release becomes active. Our recommendation is to add an independent reachability check and a small functional check appropriate to your service. Watch the customer-facing URL, relevant application errors and the availability of critical dependencies. A successful deployment is one observation. Recovery needs observations from the paths users actually take.

Give the network administrator a precise request

Prepare a short handoff containing the vendor notice, your affected domain, the time window and the comparison between working and failing connections. Ask for the relevant block or reputation decision to be reviewed. Let the administrator assess a narrowly scoped exception against their policy. Agree how to test it, who owns it and when to remove it. Keep broad firewall changes out of an improvised customer workaround.

• Identify the destination and the affected connection clearly.
• Attach reproducible observations and the current vendor notice.
• Record the owner and review time for any temporary exception.

Publish an update that customers can act on

Use an update channel your customers can reach. Say which functions you have verified, when you checked them and when the next update will arrive. Offer a support route for an urgent task. If a payment or form submission has an uncertain result, help the user check its reference before retrying. Keep the wording specific to observed impact. A status message should reduce uncertainty for the customer and give your support team a consistent response.

Close the incident with a recovery checklist

Retest from a previously failing connection and complete an authorized journey using your own test account. Confirm that critical reads work, that a test write appears once and that normal processing has resumed. Review any backlog before replaying jobs or webhooks. Record the last failing observation, first successful observation and follow-up owner. Afterwards, decide which monitoring, support or recovery task would have shortened the disruption for your users.

• Recheck the affected network and the customer-facing hostname.
• Verify a real workflow and inspect any uncertain submissions.
• Review queued work, temporary exceptions and customer updates.