Incident RCA — getraxx.com unserved (2026-05-08 UTC)

Status: Fix in PR (see #1368 comment — pending merge + re-deploy) Severity: SEV-2 — marketing front door unserved; no customer data at risk Reported: #1368 Fix PRs: #1369 (landing + workflow) · this PR (grep bug in workflow)

Timeline

Root cause

Three independent failures compounded — original two from the 2026-05-08 investigation plus a third introduced by the fix workflow:

1. No CF Pages project created. The DNS CNAME for getraxx.com pointed to getraxx.pages.dev but no CF Pages project with that name was ever provisioned. Cloudflare returns HTTP 403 for unresolvable custom hostname.

2. Landing source not standalone. The React landing page (built in commit a837db0) was embedded inside the Antlers CRA app with no standalone deployable.

3. Grep pattern assumed compact JSON. deploy-getraxx.yml checked for '"success":true' (no whitespace) but the Cloudflare v4 API returns pretty-printed JSON: "success": true (space after colon). The shell script false-negated a successful API response and aborted. The CF Pages project and custom domain attach both completed successfully; only the guard check failed.

Current state (2026-05-10)

• CF Pages project getraxx exists on the account.
• Custom domain getraxx.com was attached during the failed run (the attach succeeded before the grep check failed).
• Zero deployments exist in the project — so the domain serves HTTP 522 instead of content.
• DNS resolves correctly: getraxx.com → 104.21.6.99 / 172.67.134.179 (Cloudflare anycast, proxied).

On merge of this fix PR, deploy-getraxx.yml will re-trigger. The idempotent steps (project create, domain attach) will no-op correctly. The deploy step will upload the first artifact and the site will serve HTTP 200.

Fix

This PR patches .github/workflows/deploy-getraxx.yml:

• grep -q '"success":true' → grep -qE '"success":[[:space:]]*true' in both the getraxx.com and www.getraxx.com custom-domain-attach steps.
• Adds CF error code 8000000 (CF Pages "domain already attached") to the already_flag grep pattern, so idempotent re-runs on already-attached domains also pass.

Operator prerequisite (still outstanding)

The CLOUDFLARE_EDIT_DNS token covers the raxx.app zone only. The DNS bootstrap steps in deploy-getraxx.yml require DNS:Edit scope on the getraxx.com zone (Zone ID 0bdcee38d1da2d021eb6166f0bd6204f). Since the DNS CNAME already exists, those steps will no-op on the CNAME check and not attempt creation. The Pages deploy does not require the DNS token — the site will serve after merge regardless.

Action: Extend CLOUDFLARE_EDIT_DNS to cover the getraxx.com zone when convenient (low urgency; DNS CNAME is already correct).

Contributing factors

• No "new surface" checklist was followed when getraxx.com zone was created.
• config/status-surfaces.yaml probe_url for getraxx-com never generated an alert on 403/522 — no proactive monitoring caught this in the 18 days since 2026-04-22.
• The fix workflow was written and reviewed without a test against actual CF API response format. The CF v4 API always returns pretty-printed JSON from its domain attach endpoint; this was not verified before authoring the grep.

Action items