a month ago
Hi team,
Customer-facing production outage. ALL custom domains across multiple services in my workspace are returning the Railway edge page "Not Found / The train has not arrived at the station", despite:
- All services show Online in dashboard
- All custom domains show green checkmarks in Networking settings
- DNS is fully healthy and propagated globally
- Confirmed by multiple users in different geographies (not a client-side or local DNS issue)
Scale of impact: every custom domain on every service in this workspace is affected. This points to a workspace-level or account-level edge/ingress issue rather than a single service misconfiguration.
Affected domains (all returning edge "Not Found"):
- *.getraze.co →
DNS verification (nslookup via 8.8.8.8, also confirmed via dnschecker.org global):
- app.getraze.co → 151.101.2.15
- www.getraze.co → 151.101.2.15
All CNAMEs resolve correctly worldwide with green propagation.
Error Request IDs captured from the "Not Found" page:
- AxNd6S5gRlOpbfI09I3ezw
- 9ns4M4MjRP6ZQRjG2prcFg
Already tried:
- Removed and re-added app.getraze.co as custom domain (no effect)
- Verified all CNAME targets match Railway's UI values
- Tested from multiple networks and geographies
This looks like edge/ingress provisioning is globally broken for this workspace — even though the UI state says everything is healthy, no hostname is actually routing to any service.
Workspace: Guilherme Goullart's Projects
Environment: production
Affected services: leadraze-b2b and others (all services with custom domains)
Please force a full re-provisioning of edge routing on your side. This is a production outage impacting paying customers.
Thanks!
5 Replies
a month ago
Your app.getraze.co CNAME is pointing to 10j1viy0.up.railway.app, but after you removed and re-added the domain, the required target changed to o7pv272u.up.railway.app. Update your DNS record for app.getraze.co to point to o7pv272u.up.railway.app and traffic will route correctly. Your www.getraze.co CNAME is correct and should be working.
Status changed to Awaiting User Response Railway • about 1 month ago
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
Your domain is resolving correctly now with no 404. Can you confirm it's working on your end?
Status changed to Awaiting User Response Railway • about 1 month ago
brody
Your domain is resolving correctly now with no 404. Can you confirm it's working on your end?
a month ago
Hi @brody, this is actively broken for many users right now, not just me. Screenshots below from two different users on two different networks — both getting DNS_PROBE_FINISHED_NXDOMAIN on app.getraze.co.
Authoritative DNS resolves fine (nslookup @ 8.8.8.8 → 151.101.2.15 , dnschecker.org green worldwide ), but resolvers that real users hit are returning NXDOMAIN.
This looks like stale negative cache / broken propagation at the recursive resolver layer. Did any DNS/hostname operation happen on your side recently for this workspace that might have caused resolvers to cache NXDOMAIN?
Domains affected (all returning NXDOMAIN for most users):
- *.getraze.co
Screenshots attached.
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
Your domains are resolving correctly from our side with no errors. This is not something we can fix on our end.
Status changed to Awaiting User Response Railway • about 1 month ago
Status changed to Open Railway • about 1 month ago
brody
Your domains are resolving correctly from our side with no errors. This is not something we can fix on our end.
a month ago
Got it, thanks for checking @brody. Agreed — if it resolves from your side, the issue is upstream at my DNS provider (Hostinger). I'll take it from there. Thanks for the quick response!
Status changed to Solved Railway • about 1 month ago