Can you share the URLs? A 404 usually means your service is either offline or you don't have the proper TXT records set up on your custom domains.

The sites were running fine a while back. At some point they stopped, with no changes from me. URLs:

https://spotification-client-production.up.railway.app/

https://speech-therapy-client-production.up.railway.app/

Are the services online and healthy?

Yes

Try redeploying them.

I already did that.

Thank you @muyiez101.

I don't know if I'm using Atlas or not but my account is a hobby account and I pay very little for it (close to nothing since not much traffic with things down). Where can I check for sure if it's Atlas?

Here's what I'm seeing in the logs for spotification-server for today's redeploy:

Details

"Deployment successful"

Build Logs

All looks fine except there are 3 warnings:

2 warnings about SecretsUsedInArgOrEnv which I will fix soon but don't think they're causing the issue

1 warning about Nixpacks: "UndefinedVar: Usage of undefined variable '$NIXPACKS_PATH' (line 18)(https://docs.docker.com/go/dockerfile/rule/undefined-var/)

details: Variables should be defined before their use". This is suspicious, maybe. I don't see that variable in my variables list.

Deploy Logs

Looks good, says server started and connected to database.

There is this warning that I don't think is related to the issue: "npm warn config production Use --omit=dev instead."

Network logs

HTTP: nothing

DNS: a bunch of OK for monorail.proxy.rlwy.net

Network Flow: Seeing occasional TCP_INVALID statuses, but most statuses are OK.

And here's what I'm seeing in the logs for MongoDB for today's deploy:

Details

"Deployment successful"

Build Logs

Nothing

Deploy Logs

Lots of standard looking log entries

A mongod startup complete message, followed by Connection accepted, then Connection not authenticating (about 3 of these) followed by Connection accepted + Successfully authenticated (a couple of these), then not authenticating, then authenticated a couple times, followed by tons of WildTiger logs about Checkpointer.

Network Logs

HTTP: nothing

DNS: nothing

Network Flow: lots of entries, all with status OK

Are you sure there isn't a typo in the URLs you provided? If there isn't, try to delete the URL, and generate a new one from settings > networking.

I tested both client URLs directly. At 2026-08-26 19:19 UTC, both returned Railway’s edge fallback:

HTTP/2 404

server: railway-hikari

x-railway-fallback: true

{"status":"error","code":404,"message":"Application not found"}

This response is not coming from React, Express, MongoDB, or the containers. The hostname is not currently mapped to a routable application at Railway’s edge. The $NIXPACKS_PATH warning and Mongo logs are unrelated to this 404.

I also verified that the backends are reachable: Spotification’s /api/playlists/auth/test returns 200 Hello world, and both backend root routes return the expected Express Cannot GET /.

For each client service in the active Production environment:

1. Open Settings → Networking → Public Networking.
2. Compare the exact generated domain shown there with the URLs posted here. The Speech Therapy URL also contains an extra trailing period, although the clean hostname currently returns the same fallback.
3. If no domain appears—or Railway shows a different hostname—generate a domain and use that exact hostname.
4. If these exact domains are already attached, capture the Networking screen and deployment ID before regenerating so Railway can inspect the stale route.
5. Test the resulting hostname with curl -i; the corrected response should no longer contain x-railway-fallback: true.

This matches another Railway-generated-domain case caused by an old hostname no longer being bound to the service: https://station.railway.com/questions/railway-generated-domain-returns-x-railw-adffc3f6

If new client hostnames are generated, update the links on jaydimock.com, update CLIENT_URL on both servers, and update Spotification’s CLIENT_REDIRECT_URI before redeploying.

If the dashboard already shows these exact hostnames attached, give Railway these fresh request IDs and ask them to reconcile the edge route:

• Spotification: 3oM-r9nuQWarsCT89I3ezw
• Speech Therapy: eg4rrh56ShadCf0C2prcFg

Domain documentation: https://docs.railway.com/networking/domains/working-with-domains

Thanks, @novus777. The trailing period on the speech therapy client url that I posted was a typo -- I'll update my post to remove it.

The generated domains under client settings networking are the same as what I posted here prior (aside from that typo).

I tried regenerating the domain for spotification-client and it now has two: the original plus a new one, listed below. curl -i produces 404 with x-railway-fallback:true for the new domain as well. I thought maybe that was because the CLIENT_REDIRECT_URI and CLIENT_URL hadn't been updated to the new domain yet on the server; I went ahead and did that, and redeployed the server (successfully), then redeployed the client, but no change in outcome.

Is there a way for me to contact Railway directly about this issue? When I try to use the help link I'm just directed to community and don't have the option to contact railway (likely due to being a hobby account?)

Details:

• spotification-client
  • original generated domain: spotification-client-production.up.railway.app
  • additional newly generated domain: spotification-client-production-6ec4.up.railway.app
  • deployment id from yesterday: 973c514e-b083-47b4-8202-b10a297ac32f
  • current deployment id: 62eed20a-dc76-43db-8ad9-9fd9b0308b0a
  • networking screen:

• speech-thereapy-client
  • generated domain: speech-therapy-client-production.up.railway.app
  • deployment id: de86b050-d405-4d88-8298-59078c5b992b
  • networking screen: