Service: otwp-orders Custom domain: orders.boobandgoob.com

Custom domain ID: 88675ce0-6e38-4342-9ce4-96e344be563a Registered via customDomainCreate (project token, server-side) ~9 hours ago (verifiedAt 2026-05-06T18:15:56Z) Status today via your domains query: certificateStatus: CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP targetPort: 3000 dnsRecords[0].status: DNS_RECORD_STATUS_PROPAGATED

dnsRecords[0].requiredValue: xo6ty2zp.up.railway.app Verified on our side: - DNS propagated externally — dig CNAME orders.boobandgoob.com @1.1.1.1 and @8.8.8.8 both return xo6ty2zp.up.railway.app - No CAA blocking - openssl s_client to orders.boobandgoob.com:443 still serving your wildcard *.up.railway.app cert (Let's Encrypt R12) - crt.sh shows zero certificate attempts for boobandgoob.com — Let's Encrypt has never been asked - targetPort is set (3000) — confirmed via your domains query This is the second time today a custom domain on this service has gotten stuck in VALIDATING_OWNERSHIP for hours with no cert ever requested. The prior stuck registration was recovered by detach + reattach. We're about to try detach + reattach again, but if the cert queue is genuinely broken for our service, that won't help. Could you check why this domain ID's cert flow isn't being dispatched to Let's Encrypt, and whether something needs unsticking on our service's queue?

Project token in use is a UUID-format project access token attached to this service.

Submit at https://help.railway.com — pick "Bug" or "Networking/Domains" category. Mention you're on a paid plan if you are; gets faster routing. If the third detach/reattach succeeds before they reply, you can close it. If it fails the same way, the ticket already has everything they need.