The domain is currently serving traffic normally through our edge with no fallback or routing errors. DNS, certificate, verification, and edge routes all check out, and recent requests are returning 200 responses. If you are still seeing "Site not available," it may be a cached response in your browser or a local DNS resolver that has not refreshed yet. Try a hard refresh or test from an incognito window.

The "200 responses" are misleading — Railway's "Site not available" placeholder page is itself served with HTTP 200. I tested with curl from a clean server (no browser cache, no local DNS resolver involved) and the body is still your "Site not available" page, not my app. My identical www.ismsuk.com on the same service serves the real app correctly. So the edge is NOT routing www.albatrosseducation.com to the service — please have a human repair the internal route for this hostname.

The edge is routing the affected domain to your service correctly, and the "Site not available" page is being generated by your deployment, not by Railway. Railway's fallback page always includes an x-railway-fallback header, and that header is absent here. The response also carries your deployment's own static assets, the same bundle your working domain serves, which confirms the request reaches your running app.

One factual difference we observed between the two hostnames: responses on your working domain include a rewrite header added by your application, while responses on the affected domain don't. Since the response originates inside your deployment, there's nothing to repair on the routing side, and deleting or re-adding the domain won't change what your app returns for that hostname.