My custom domain www.offerbound.io has been stuck in CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP with an empty certificates array for over 24 hours, across multiple delete + re-add cycles. Your AI agent confirmed it can't access LE issuance logs or rate-limit state and recommended I escalate here. Could you check the Let's Encrypt issuance logs on the backend and tell me whether I've tripped the 5-duplicate-certs-per-week rate limit, or whether there's a different validation failure I can act on?

IDs

• Project: c2bda7fe-3273-46b5-a635-018201b6e043
• Environment (production): e2adc985-a3a6-4832-9670-291a89be493c
• Service resume: 8fdcf6ae-db48-4403-9e10-fb2fdf83838f
• Current www custom domain: db062a82-ce1a-4a9d-853d-ba6ff234ba34
• Domain: www.offerbound.io
• Status: CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP (stuck 24+ hours)

Diagnostics already verified on my side

• DNS: www.offerbound.io CNAME → 91gjwxh7.up.railway.app, propagated on both 1.1.1.1 and 8.8.8.8.
• Your own GraphQL domains(...) status reports DNS_RECORD_STATUS_PROPAGATED with currentValue == requiredValue.
• DNS provider: Cloudflare. The www record is DNS only (gray cloud) — Cloudflare proxy is not in the validation path.
• CAA: no CAA records on offerbound.io or www.offerbound.io — Let's Encrypt is not blocked at the CA level.
• DNSSEC: not enabled on the zone.
• HTTP-01 challenge path is reachable from the public internet: http://www.offerbound.io/.well-known/acme-challenge/test returns a Railway-edge 404 (port 80 open, your edge is serving requests for that host with x-railway-edge headers and server: railway-edge).
• TLS-ALPN-01 negotiation against port 443 returns the wildcard *.up.railway.app cert (no acme-tls/1 ALPN response), suggesting the cert hasn't even reached the issuance attempt phase.
• The apex offerbound.io was originally a Railway custom domain alongside www but I removed it (Cloudflare's apex CNAME flattening was making the multi-SAN validation flap). The apex now lives behind Cloudflare's proxy with a Redirect Rule pointing to https://www.offerbound.io, so it is no longer Railway's concern.

Timeline of delete/re-add cycles (UTC, approximate)

• 2026-04-23: original setup with Namecheap ALIAS at the apex; both offerbound.io and www.offerbound.io added to Railway; both stuck in VALIDATING_OWNERSHIP for 24+h.
• 2026-04-25: migrated DNS away from Namecheap to Cloudflare (NS: iris.ns.cloudflare.com / skip.ns.cloudflare.com); deleted + re-added both apex and www on Railway with new CNAME targets; both still stuck.
• 2026-04-26 ~22:15: deleted apex custom domain (6b367a1b-f8ad-49d2-9751-f242bb37d6f9) from Railway. www remained (4e843ace-6c92-4eae-ae95-5e2cda0244c1).
• 2026-04-26 ~22:35: deleted www (4e843ace-...) and re-created it. New id: db062a82-ce1a-4a9d-853d-ba6ff234ba34, new CNAME target 91gjwxh7.up.railway.app. Cloudflare DNS was updated to the new target within ~2 min and Railway confirmed DNS_RECORD_STATUS_PROPAGATED shortly after.
• 2026-04-26 22:50 onward: status has remained VALIDATING_OWNERSHIP with empty certificates array. Last GraphQL check: still stuck.

So across ~3 days I have at least 4 delete + re-add cycles for www.offerbound.io and a similar number for the apex. This is the main reason I suspect the LE 5-duplicate-certs-per-week rate limit; everything else in the validation chain looks correct from my side.

Asks

1. Please check the Let's Encrypt issuance logs for www.offerbound.io and share the actual challenge failure reason (HTTP-01 fetch URL + result, TLS-ALPN-01 result, etc.).
2. Have I hit the LE 5-duplicate-certs-per-week rate limit? If yes, when does the oldest attempt roll off so I know when issuance can resume?
3. If not rate-limited, can you manually retry issuance from your side or surface the underlying error in the dashboard?
4. If rate-limited and unblockable for several days, can you confirm whether putting the domain behind Cloudflare's proxy in Full SSL mode (so visitors hit a Cloudflare edge cert and Cloudflare proxies to your wildcard origin) is supported as a temporary workaround? I'd like to revert to a Railway-issued cert once the LE limit clears.

Workaround currently planned while we wait I'm about to switch www to Cloudflare proxied (orange cloud) with SSL/TLS mode set to Full (not Strict, since the origin will keep presenting *.up.railway.app). This gets HTTPS working for end users and removes the dependency on Railway's LE flow. Please flag if this conflicts with anything on your edge.

Thanks — happy to provide any additional logs/timestamps.