Project: kinky-assignments (0452609a-fc5b-4bb3-855c-5cd6a435e3f3)

Environment: production (067720d1-42af-4ba9-a2dc-2e4cddd11468)

Service: web (82daafb6-a281-4d0b-8735-2e5fb88a813f)

Custom domain: app.kinkyassignments.com (ae285163-86f0-4aad-b296-ebacb9c41bf0)

The domain has been sitting in CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP since roughly

16:00 UTC on 20 August. The certificates array is empty. Everything on our side matches what

the API asks for.

What the API returns:

targetPort: 8080

certificateStatus: CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP

certificates: []

dnsRecords:

recordType: DNS_RECORD_TYPE_CNAME

hostlabel: app

currentValue:  wxn1djuy.up.railway.app

requiredValue: wxn1djuy.up.railway.app

status: DNS_RECORD_STATUS_PROPAGATED

purpose: DNS_RECORD_PURPOSE_TRAFFIC_ROUTE

What we have already checked and ruled out:

• DNS resolves correctly and is not proxied. dig app.kinkyassignments.com returns the CNAME

  wxn1djuy.up.railway.app and then 69.46.46.90, so traffic reaches your edge directly. The

  record is grey-clouded in Cloudflare, DNS only.

• No CAA records on kinkyassignments.com or on the subdomain.

• Port 80 is reachable on the hostname and answers from railway-edge. A request to

  http://app.kinkyassignments.com/.well-known/acme-challenge/ returns a 404 from

  railway-edge, so the ACME HTTP-01 path is being served rather than redirected away.

• The service itself is healthy. It listens on 8080 (confirmed in the deploy logs, "Network:

  http://0.0.0.0:8080") and the generated domain web-production-5f32f.up.railway.app works

  normally over HTTPS.

• Only one DNS record is listed as required, with purpose TRAFFIC_ROUTE. No TXT verification

  record is requested, which matches the docs for a non-wildcard domain.

What we already tried:

• Deleted and re-created the custom domain once. That issued a new CNAME target, which we

  updated in Cloudflare; the API now reports currentValue == requiredValue.

• Corrected targetPort from 3000 to 8080 via customDomainUpdate.

• Called customDomainIssueCertificate, which returned true. Nothing changed after that.

Could you check what the issuance job is doing for this domain? Happy to delete and re-add

again if that helps, but we would rather not churn the CNAME target a third time without

knowing whether that is the actual fix.