Hi all,

Hoping someone can point me in the right direction. I've got a custom domain that's been stuck in "validating ownership" for three days now and I've run out of things to check on my end.

The details:

• Project: serene-enjoyment (03231e3d-8500-484d-8462-3a85d2a8fcda)
• Environment: production (5c622ff3-a3d7-4e99-a550-f4a992e7190e)
• Service: RouteMap (f349cbec-4cf4-45d4-a5ea-a11122e2ab01)
• Custom domain: routemap.mandooist.com (ad1a7a98-a1ec-4bff-94c9-62f65205424c), target port 3000
• Railway domain on the same service: routemap-production.up.railway.app, which works fine

It's been like this since 2026-09-05 11:28 UTC. The edge answers on the right IP, but it serves the *.up.railway.app wildcard cert for my hostname, so every HTTPS request dies in the handshake:

$ echo | openssl s_client -connect routemap.mandooist.com:443 -servername routemap.mandooist.com
subject=CN=*.up.railway.app
issuer=C=US, O=Let's Encrypt, CN=YE1
notBefore=Jul 29 02:40:55 2026 GMT   notAfter=Oct 27 02:40:54 2026 GMT

$ curl https://routemap.mandooist.com/health
schannel: SNI or certificate check failed: SEC_E_WRONG_PRINCIPAL - the target principal name is incorrect

So as far as I can tell no certificate has ever been issued for it. The service itself is healthy, https://routemap-production.up.railway.app/health comes back 200 in well under a second.

Things I've already checked:

• DNS is correct and propagated. routemap.mandooist.com is a CNAME to 8z992xpw.up.railway.app (verified against 8.8.8.8), resolving to 69.46.46.0. It's DNS-only at Cloudflare, not proxied.
• No CAA records, on either the apex or the subdomain.
• ACME paths reach the edge, and port 3000 is bound and serving.
• I've deleted and re-added the domain, and redeployed the service. No change either time.
• It isn't specific to this hostname. On 2026-09-07 I added api.mandooist.com purely as a probe and that wouldn't issue either, so I removed it again. That's what makes me think it's something about the service or the account rather than the name.

Is there any way to see what the ACME order is actually doing, or whether one was ever created? And if anyone from Railway is able to look at domain ad1a7a98-a1ec-4bff-94c9-62f65205424c, I'd really appreciate it. Happy to try anything else in the meantime.

Second thing while I'm here, possibly related since it's the same service.

On 2026-09-07 at 12:45:28 UTC one of my users got a 504 from routemap-production.up.railway.app on GET /api/auth/config. The request never reached my process. I log a line per /api request and there's a 51 minute gap right across it:

11:54:48Z  [API] GET /api/auth/config 200 1ms
           (client got a 504 at 12:45:28Z, nothing logged this end)
12:46:07Z  [API] POST /api/auth/forgot-password 200 66ms
12:46:47Z  [API] GET /api/auth/config 200 0ms

No restart or boot lines anywhere in that window, so nothing crashed or redeployed. The deployment (1c8444b2-7b5a-4219-8a05-b7decaeead88) started at 2026-09-07T00:01:52Z and has been up ever since. App sleeping is off (sleepApplication: false), one replica, us-west2. Then 39 seconds later the same endpoint served in 0ms.

My read is that the edge lost its route to an idle but perfectly healthy instance, and the first request after the quiet period wore it. I couldn't pull the HTTP logs for that window to check upstreamErrors, they're past retention by now.

Couple of questions:

1. Is that expected for a V2 service with one replica and sleeping disabled?
2. Is there a supported way to keep the route warm, other than just throwing synthetic traffic at it?

I've put a healthcheck on /health and a five minute self-ping in for now, but I'd rather not paper over something that can be fixed at the edge.

Thanks,

Jason