Project: Baton (ID: 05456edd-5aab-49dd-b119-1e838d552646)

Environment: production (ID: 73187661-4a53-4ebc-9bb6-bce50e36d655)

Service: baton-app (ID: 38821789-10d8-4113-b945-2733b9c8d93c)

Custom Domain: app.runwithbaton.com (ID: fb9add08-f8d5-40fa-8278-82892b08c2f5)

CNAME Target: gppvowkf.up.railway.app

Issue: SSL/TLS certificate issuance is stuck in CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIPfor 6+ hours. Let's Encrypt has never issued a certificate for this domain (verified via crt.sh — zero certificates on record).

Verification Completed:

• DNS: CNAME correctly propagated to gppvowkf.up.railway.app (verified externally via dig @1.1.1.1 and Railway GraphQL dnsRecords.status: DNS_RECORD_STATUS_PROPAGATED)
• Cloudflare proxy: OFF (DNS-only, grey cloud)
• CAA records: Clean, no restrictions
• HTTP connectivity: Service listening on port 80 at gppvowkf.up.railway.app
• App code: No HTTP→HTTPS redirects; Fastify configured correctly
• ACME challenge path: /.well-known/acme-challenge/* returns 404 (not a redirect)
• App logs: Zero requests to /.well-known/acme-challenge/ — challenge is handled at Railway's edge, not forwarded to origin

Root Cause: Railway's edge proxy returns 404 on the ACME challenge path because no pending challenge exists in Railway's cert-provisioning pipeline. This indicates Railway's internal ACME client is not queueing a challenge for this domain.

Troubleshooting Attempted:

• Deleted and recreated custom domain twice (Railway issued fresh CNAME targets each time; DNS updated to match)
• Toggled Cloudflare proxy off
• Verified service health and HTTP connectivity

Request: Please manually trigger ACME issuance for app.runwithbaton.com. Check internal ACME/Let's Encrypt client logs to determine why the challenge was not queued when the custom domain was created.