We found a stuck certificate pipelines on this service. Your service domain had its verification stall before your DNS propagated, so it never re-ran after your records were set correctly. Your DNS for the custom domain is actually configured properly on both the CNAME and TXT verification records, so no changes needed on your side. We've triggered certificate re-issuance on both domains, which should complete within a few minutes and bring edge routing online for both.

Hi, thanks for the quick first pass. Unfortunately the certificate re-issuance did not fix it — as of 01:05 UTC (over an hour after your trigger) the service domain is still returning the fallback 404 from the cdg1 edge:

{"status":"error","code":404,"message":"Application not found"}

Headers: server: railway-hikari, x-railway-fallback: true, x-railway-edge: cdg1

Fresh request IDs: 4D1m7GEQQ82rO9JWs_GTAg (00:52:30 UTC), ptWsktYcTMaZhxd8YqdHTg (01:05:00 UTC)

One important detail: the edge terminates TLS for kin-co-ai-platform.up.railway.app with the shared *.up.railway.app wildcard certificate (Let's Encrypt YE1, serial 06DA79BB561DA3EFEB0E751CA21ABD3999FE) — the handshake works fine. So the service domain's failure is not certificate-related: the edge simply has no hostname→deployment route binding. Please re-sync/re-publish the edge route for this hostname at cdg1.

On the custom domain: thank you for confirming the DNS — we verified the same independently (CNAME → tvepwoug.up.railway.app and the _railway-verify TXT are both live). However, the CNAME target IP (69.46.46.85) is not accepting TCP connections on 443 from our European vantage (connection hangs), while 69.46.46.94 answers normally on the same path. Please check listener/anycast health for that target in the EU region.

For context: the deployment itself is healthy — from a US vantage we get HTTP 200 and a fully passing smoke suite on the latest deployment (4f6c9384-b9b2-4a9d-b54c-4972e765c381, 23:14 UTC). And I've noticed today's community reports of the identical x-railway-fallback per-edge issue at ams1 — this looks like a broader edge route-publication problem today rather than per-service certificate issues, so I'd appreciate escalation to the edge/networking team.

Project: 65601b54-5ec9-47f1-8496-88fa6ae1b0e5 · Service: 7f57f167-a319-4446-abfc-80e8dbeca62e

Happy to run any further checks you need from our side.

Both domains are now serving traffic correctly. Our edge probes show HTTP 200 with no fallback on both kin-co-ai-platform-production.up.railway.app and aidashboard.kinandcostays.com, with routes installed and server: railway-hikari responding normally.

To your incident question: no platform edge incident is currently active or was active at the time of your report. The edge route binding for the service domain has recovered, though the exact trigger is not clear from our side - the earlier certificate re-issuance may have eventually propagated the route state.