Summary

Two custom domains in the same project have been stuck in CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP for hours, while five other custom domains in the same project have CERTIFICATE_STATUS_TYPE_VALID. All seven have the same configuration pattern (CNAME to a unique *.up.railway.app target, cdnMode: off, targetPort set to the service's listen port, DNS DNS_RECORD_STATUS_PROPAGATED). No certificateErrorType is reported on either stuck domain. Both were created today (2026-04-16).

Environment

• Workspace: kbibelhausen's Projects
• - Project: studiob-platform (433dec0e-6963-4b66-bdd2-6049ba189b81)
• - Environment: production (44268465-5f2c-4ec4-8b77-f29e5b16f0f8)
• - Plan: Pro

Stuck custom domains

1. bolt.b.studio — service bolt-site

• customDomain id: 0a753cb8-9ce6-4dfe-b6ca-5e3616d6ee92
• - service id: 78e71476-2789-4604-81fa-0cfa1b3245e2
• - created: 2026-04-16T22:14:21.962Z
• - cdnMode: off
• - targetPort: 8080
• - DNS: bolt.b.studio CNAME wushzjrm.up.railway.app (required = current, DNS_RECORD_STATUS_PROPAGATED)
• - certificateStatus: CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP
• - certificateErrorType: null
• - certificates: []

2. orderhub.b.studio — service studiob-api

• customDomain id: b4f98aef-b8d8-4e6c-999c-b7c1703c3b9c
• - service id: df0e34d5-4890-471e-8a6c-deced8339930
• - created: 2026-04-16T19:54:18.854Z
• - cdnMode: off
• - DNS: orderhub.b.studio CNAME ammcs2ff.up.railway.app (required = current, DNS_RECORD_STATUS_PROPAGATED)
• - certificateStatus: CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP
• - certificateErrorType: null
• - certificates: []

Working custom domains in the same project (for contrast)

All five of these are CERTIFICATE_STATUS_TYPE_VALID, same project, same cdnMode: off, same DNS setup pattern:

• internal.asthetik.com → webhook-router
• - samples.asthetik.com → webhook-router
• - dashboard.b.studio → business-dashboard (HTTPS 401, auth-gated, working)
• - docs.b.studio → studiob-docs (HTTPS 200)
• - board.asthetik.com → quarterbook

What I've already verified

• DNS propagated globally (confirmed via dig @1.1.1.1 and dig @9.9.9.9 for both domains; currentValue matches requiredValue in the custom-domain status).
• - HTTP (port 80) requests to both stuck domains reach Railway's edge — response headers include server: railway-edge and x-railway-cdn-edge: fastly/...
• - /.well-known/acme-challenge/* paths on both domains are intercepted at Railway's edge (returning 404 for unknown tokens — standard behavior, confirms the ACME path is not being 301-redirected to HTTPS).
• - No CAA records on b.studio (verified via dig b.studio CAA) — not blocking any CA.
• - HTTPS probe against both stuck domains returns the CN=*.up.railway.app wildcard cert (subjectAltName mismatch) — indicates the custom-domain cert was never provisioned, not that it was provisioned and failed.
• - Tried deleting and recreating the bolt.b.studio custom domain once (that's why its ID is the second attempt — first ID was 4d9764a2-595b-4890-a0d8-2df951903885, deleted after ~10 min stuck). New creation returned a fresh CNAME target, DNS was updated via our registrar accordingly, but the new custom domain is stuck in the same state.

What I think is going on

Railway's certificate provisioning pipeline seems to have skipped these two domains. Same config, same project, same DNS pattern as the five working domains — only difference I can identify is that these two were created today. No certificateErrorType suggests no validation attempt actually failed; the state just never advances out of VALIDATING_OWNERSHIP.

Ask

Please kick the cert issuance for both domains. If there's something specific I need to do on my side (e.g., different DNS record, different CDN mode) that isn't surfaced via customDomain { status { dnsRecords } }, let me know.

Thank you.

— Kevin Bibelhausen, Principal, Studio B AI — kevin@b.studio