No TLS certificate is ever issued for custom domains on this service. Two different domains, added 11 hours apart, are both stuck at CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP while DNS is reported as DNS_RECORD_STATUS_PROPAGATED and currentValue matches requiredValue. The service is the one selected below; I can share project and service IDs privately if you need them.

app.theravalab.com, created 2026-08-19 23:02:39 UTC, target j6x7daal.up.railway.app

gym.theravalab.com, created 2026-08-20 09:48:45 UTC, target isnym76i.up.railway.app

The very first custom domain for app.theravalab.com was created at 2026-08-19 14:02:57 UTC, so this has been failing for over 20 hours. gym.theravalab.com was added only as a control, to check whether the problem was specific to the first entry. It is not: both behave identically.

What I verified before posting:

DNS is correct and propagated. app.theravalab.com resolves to j6x7daal.up.railway.app from 1.1.1.1, 8.8.8.8, 9.9.9.9, 208.67.222.222 and from the authoritative nameserver (Hostinger). TTL is 300.

Railway's own API agrees: DNS_RECORD_STATUS_PROPAGATED, and currentValue equals requiredValue for both domains.

No CAA records exist on theravalab.com or on the com TLD, so nothing restricts issuance.

The edge is routing the host: http://app.theravalab.com/login returns 301 to https with Server: railway-edge.

The ACME path is reachable and correctly excluded from the HTTPS redirect: http://app.theravalab.com/.well-known/acme-challenge/test returns 404 from railway-edge rather than a 301, which suggests no challenge is ever pending.

TLS terminates but with the wrong certificate: the handshake succeeds and the edge presents CN=*.up.railway.app instead of a certificate for the custom domain, so clients fail verification (curl exit 60).

status.railway.com reported Operational throughout.

One more observation that may be unrelated but looked odd: for several hours the API reported a currentValue pointing at the target of an earlier custom domain entry that had already been deleted, while every public resolver and the authoritative nameserver returned the current value. It corrected itself later. It looked like a stale resolver cache on Railway's side.

Could someone force certificate issuance for these two domains, or tell me what is blocking ownership validation? If the entries are wedged and need recreating from your side, I would rather you did it: every delete/create mints a new up.railway.app target, and re-pointing DNS each time just restarts the race against DNS caches.