Single-account escalation
High confidence
STARK-44 (enterprise) is failing checkout likely because a recent production deploy started enforcing a customer_org claim that this account does not have configured.
What Nirna found
-
Account STARK-44 is on the enterprise plan, status active; its claims show customer_org is not_configured while email and name are enabled.source ↗
-
Recent orders for STARK-44 were successfully placed earlier (e.g., ord_a6c8139fab16 on 2026-07-23 22:41:35 UTC).source ↗
-
Another order for STARK-44 the same day was also placed successfully (ord_705e75a37232).source ↗
-
A production deploy to the bindu-bazaar service occurred at 2026-07-25T02:11:18+00:00.source ↗
What this means
Given reports of recent checkout failures and that STARK-44 is an enterprise account with the customer_org claim not configured, it’s likely the latest production deploy introduced or tightened a requirement for this claim on the enterprise checkout path; because STARK-44 lacks it, requests may now 500 where they previously succeeded, explaining why prior checkouts worked and new ones fail.
Who’s affected
Accounts affected
1
isolated so far
First seen
Jul 25 · 02:11 UTC
Also affects: STARK-44
Recommended fix
Ops change
In the internal Claims/SSO mapping tool: 1) Open account STARK-44. 2) Under Claims, locate key `customer_org` and change status from `not_configured` to `enabled`. 3) Map it to the IdP/OIDC claim named `customer_org` (exact key: `customer_org`). 4) Save changes, then run “Sync claims now” for STARK-44. 5) Ask the customer to retry checkout and confirm success; monitor for any remaining 5xx for this account.
Suggested replies
Copy-paste ready. Your engineer edits and sends.
Customer reply
Thanks for the heads‑up. We found your enterprise org was missing an SSO claim our checkout now expects. We’ve enabled the customer_org claim for STARK-44 and synced your profile. Please retry checkout and let us know if anything still fails (a timestamp and any request ID from the error screen would help).
Internal note
Hypothesis: deploy began enforcing enterprise claim `customer_org`; STARK-44 lacks it. Evidence: STARK-44 enterprise with `customer_org: not_configured` (e1); prior orders succeeded (e2, e3); recent prod deploy (e5). Action taken: In Claims admin, set STARK-44 -> claim `customer_org` to enabled, mapped to IdP claim `customer_org`, saved, and ran on-demand claim sync. Next: watch logs for 5xx on STARK-44 checkout, and confirm customer retry succeeds.
Why Nirna reached this conclusion
Verdict — Single-account escalation. Only this account is affected; the evidence points to account configuration mismatch.
Confidence — High. Several checks came back strong: account matched from ticket text, recent deploy touched failing path, account configuration mismatch.
Who fixes it — Ops change. Your ops team can fix this without a deploy — the cause is configuration, an entitlement, or a stale cache they already control.
Who’s affected. Only the reporting account is affected in this window.
| Signal | Score |
|---|---|
| Account matched from ticket text | 0.95 |
| Recent deploy touched failing path | 0.96 |
| Account configuration mismatch | 1.00 |
| Code change in the failing path | 0.00 |
| Feature-flag rollout mismatch | 0.00 |
| Patterns matched in your data | 1.70 |
| Similar recent tickets | 0.00 |
| Different accounts affected | 0.00 |
Was this triage right?
Corrections apply the same day. A wrong-account correction with a domain hint updates the routing rules for the next ticket automatically.