Hi Railway team,

Our custom domain eu.otel.confident-ai.com has been stuck on "Issuing TLS certificate" for over an hour, and the edge is serving an expired certificate, causing a production outage for our EU customers.

Service details:

Project: Honest Dolphin (22fb7f66-ed07-448b-9b9b-a6d7aaff2321)

Environment: EU (2be6ccf9-6026-411c-9382-429bddeea969)

Service: otel-server (8015a312-005e-42f1-83af-cac1ff63bf81)

Domain: eu.otel.confident-ai.com → target port 8080

What's happening:

The edge at qcgqlece.up.railway.app (69.46.46.106) is serving a Let's Encrypt cert that expired Jun 1 2026 (serial 062DD878A9305E5EA919086ED1C072FAB9D7), so TLS-verifying clients fail.

Certificate Transparency logs show a valid LE cert for this exact hostname was issued 2026-05-09 (expires 2026-08-07) — but your edge never picked it up.

The Railway-generated domain on the same service (railway.eu.otel.confident-ai.com) serves a valid cert, so this is isolated to the custom domain.

What we've already verified/tried on our side:

DNS: CNAME → qcgqlece.up.railway.app, resolving correctly, DNS-only (not Cloudflare-proxied)

No CAA records blocking issuance; DNSSEC validates cleanly (checked via Google/Cloudflare/Quad9 resolvers)

Deleted and re-added the custom domain — it returned to "Issuing TLS certificate" but the edge still serves the expired cert ~1h later

Note: earlier today this hostname's DNS pointed at a decommissioned host (since corrected), so your ACME client may have accumulated failed validations and be stuck in backoff or hit an LE rate limit.

Ask: please force re-issuance (or deploy the existing valid May 9 cert) for eu.otel.confident-ai.com. This is customer-impacting — EU trace ingestion is down on the primary hostname.

Thanks,

Yekta

yekta@confident-ai.com