Single-account escalation
High confidence
STARK-44’s enterprise checkout 500s likely started after today’s production deploys began enforcing a customer_org claim that this account doesn’t have configured.
What Nirna found
-
Account STARK-44 is active on the enterprise plan; claims show email/name enabled but customer_org is not_configured.source ↗
-
Recent orders for STARK-44 (e.g., ord_a6c8139fab16) completed with status placed on 2026-07-23.source ↗
-
Another recent order for STARK-44 (ord_705e75a37232) completed with status placed on 2026-07-23.source ↗
-
A new production deploy (nirna-production) went out at 2026-07-25T01:49:59Z.source ↗
-
An earlier production deploy (nirna-production) also went out at 2026-07-25T01:14:29Z.source ↗
What this means
Checkout worked for STARK-44 previously (orders placed on 2026-07-23), and multiple production deploys landed today; their enterprise account lacks a configured customer_org claim. It’s likely the new codepath started requiring this claim for enterprise checkout, and the missing mapping for STARK-44 is causing the 500 rather than a graceful validation error.
Who’s affected
Accounts affected
1
isolated so far
First seen
Jul 25 · 01:14 UTC
Also affects: STARK-44
Recommended fix
Ops change
Internal operational steps:
- In Admin > Accounts > STARK-44 > Claims (db link: db://account_state/STARK-44), change claims.customer_org from not_configured to enabled.
- Set the customer_org claim value/mapping to the literal string "STARK-44" for this account (so downstream checkout code receives a non-empty org identifier).
- Save, then run a test checkout on STARK-44 and confirm the flow returns 200 and creates a placed order.
- If errors persist, temporarily disable the customer_org enforcement toggle for STARK-44 only and re-test, then re-enable after engineering confirms a graceful validation path is deployed.
Suggested replies
Copy-paste ready. Your engineer edits and sends.
Customer reply
Thanks for the report — we found a misconfigured org-claim on your STARK-44 enterprise account that likely caused the checkout 500s. We’ve updated your account settings to provide the required customer_org value and expect checkout to be unblocked. Please retry a checkout and let us know the timestamp and any order ID if you still see an error; we’re monitoring on our side.
Internal note
Hypothesis: new code started requiring customer_org for enterprise checkout; STARK-44 has that claim not_configured (e1). Today saw multiple prod deploys (e5, e9). Action: In Admin > Accounts > STARK-44, set claims.customer_org=enabled and map value to "STARK-44". Then run a test checkout and confirm success. If still failing, temporarily disable the customer_org enforcement for STARK-44 and gather logs around the attempt. Links for context: db://account_state/STARK-44; recent placed orders for baseline: db://recent_orders/ord_a6c8139fab16 (e2), db://recent_orders/ord_705e75a37232 (e3).
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.