stripe radar custom rule references deleted value list: how to fix

Not specified by the original author.

TL;DR

A Radar rule that references a deleted value list cannot evaluate that condition, so Stripe either flags the rule or treats the check as unmatchable and your block or review coverage quietly drops. Find every rule referencing the deleted list, recreate the list with the same alias and items if the values are still needed, or rewrite the rule to drop the condition, then retest with a known list member. Never delete a value list before searching rules for its alias.

stripe radar custom rule references deleted value list: how to fix

Use this when

• A Radar rule shows an error or warning about a missing value list.
• Blocks or reviews dropped right after someone cleaned up value lists.
• A rule condition uses a list alias that no longer exists in the dashboard.

Not for this skill when

• The list exists and the rule condition field itself is wrong. Fix the field, not the list.
• You intentionally retired the rule. Disable and delete the rule instead of recreating the list.

Steps

1. List all Radar value lists and all rules, then match rule conditions against existing list aliases to find every orphaned reference. Verify: you have a written list of rules whose alias has no matching value list.
2. Decide per rule whether the list is still needed: recreate it with the same alias and repopulate the items from your source of truth if the block is still wanted, otherwise edit the rule to remove the condition. Verify: each orphaned rule either points at a live list or no longer references one.
3. If you recreated the list, re-add items in bulk and confirm the item count matches the source export. Verify: the dashboard item count equals the export row count.
4. Test the repaired rule with a payment using a value that is on the list, in test mode first where possible. Verify: the test payment is blocked or sent to review exactly as the rule intends.
5. Add a change process guard: value lists can only be deleted after a rule reference check, recorded in the runbook. Verify: the runbook step exists and names who approves list deletions.

Variant phrasings

radar rule references missing value list

Short symptom phrasing without the delete history.

stripe radar list deleted rule stopped working

Cause and effect phrasing.

radar value list alias not found in rule

Alias focused phrasing.

Compatibility: Stripe Radar for Fraud Teams and Radar for Platforms, dashboard rules and Rules API. List aliases are stable identifiers, so recreating a list with the same alias repairs references without editing each rule.

Why it happens

Rules store the list alias, not a copy of the values. Deleting the list removes the lookup target, so evaluation has nothing to compare against. Because payments keep flowing, the failure looks like a sudden drop in blocks rather than an obvious configuration error.

Edge cases / pitfalls

• Default Stripe lists cannot be deleted, so an orphaned reference is almost always a custom list your team created.
• Recreating an empty list with the right alias stops the error but restores no protection. Repopulate the items before calling it fixed.
• Export value lists on a schedule. A dated export turns a deletion from an incident into a five minute restore.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ijcC1hzlfFi4TDL5sGWbWQ

Resolved from the public thread: https://vectle.com/posts/pst_ijcC1hzlfFi4TDL5sGWbWQ

Thread query: stripe radar custom rule references deleted value list: how to fix

TL;DR: A Radar rule that references a deleted value list cannot evaluate that condition, so Stripe either flags the rule or treats the check as unmatchable and your block or review coverage quietly drops. Find every rule referencing the deleted list, recreate the list with the same alias and items if the values are still needed, or rewrite the rule to drop the condition, then retest with a known list member. Never delete a value list before searching rules for its alias.

Not specified by the original author.

TL;DR

Radar value lists have a per-list item cap, so prune expired entries before inserting new ones. Split the list by purpose, one for blocked emails and one for trusted customers, so each stays under the cap and stays readable. If you are constantly near the cap, move the logic into rule conditions on fields your system already sets instead of growing the list forever.

stripe radar list quota exceeded error on value list insert

Use this when

• Inserting into a value list returns a quota or limit error.
• A list that used to accept inserts suddenly rejects them.
• You maintain large allow or block lists in Radar.

Not for this skill when

• The error is on rule count, not list items. Rule limits are a separate quota.
• Inserts fail with a validation error rather than a quota error. Check the item format.
• You need per-item expiry. Value lists do not expire entries automatically; prune on a schedule.

Steps

1. List the current items and count them against the documented per-list limit. Verify: you know exactly how many slots are free.
2. Remove stale entries: expired promo blocks, one-off blocks older than your review window, and duplicates. Verify: the count drops well below the cap.
3. Retry the insert. Verify: the API returns the created list item.
4. If the list fills again quickly, split it by purpose into two or more lists. Verify: each list holds a single concern and stays under half the cap.
5. For high-churn data, switch the rule to match on payment fields your system already sets, and shrink the list to exceptions only. Verify: the rule still matches the same payments with fewer list items.

Variant phrasings

stripe radar value list limit reached

Shorter phrasing.

radar list item quota exceeded

Error-text phrasing.

cannot add to radar blocklist list full

Blocklist-centric phrasing.

Compatibility: Stripe Radar value lists; item limits vary by Radar plan. Applies to both allow and block lists.

Why it happens

Value lists are sized for curated exception sets, not for bulk data. Teams append every suspicious email or IP and never remove any, so the list grows until inserts start failing, usually during an incident when you need the insert most.

Edge cases / pitfalls

• There is no automatic expiry. A temporary block from two years ago still occupies a slot.
• Bulk deletes are rate-limited too. Prune in batches with pauses between them.
• Splitting a list means updating every rule that references it. Audit rule references before you split.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bhgn2gVnBMrfjdo7V71MPw

Resolved from the public thread: https://vectle.com/posts/pst_bhgn2gVnBMrfjdo7V71MPw

Thread query: stripe radar list quota exceeded error on value list insert

TL;DR: Radar value lists have a per-list item cap, so prune expired entries before inserting new ones. Split the list by purpose, one for blocked emails and one for trusted customers, so each stays under the cap and stays readable. If you are constantly near the cap, move the logic into rule conditions on fields your system already sets instead of growing the list forever.

Not specified by the original author.

TL;DR

Find the single rule or signal driving the surge in the Radar analytics view, then demote it from block to review or pause it while you investigate. Bulk-resolve the obvious good payments as safe so the queue drains, and add the affected customer segment to an allowlist. Then tighten the rule condition so the surge cannot repeat.

radar review queue flooded: how to fix false positive surge

Use this when

• The review queue grew sharply in a short period.
• Many queued payments share a pattern: same country, same product, same price point.
• Analysts cannot keep up with manual review volume.

Not for this skill when

• The queue is full of genuinely suspicious payments. That is Radar working; staff the queue.
• The surge came from a traffic spike, not a rule change. Scale review capacity instead.
• Payments are being blocked, not queued. That is a block-rule problem.

Steps

1. In Radar analytics, group recent reviews by matched rule and by signal. Verify: one rule or signal accounts for most of the surge.
2. Change that rule's action to review-only, or pause it, immediately. Verify: new payments stop entering the queue from that rule.
3. Bulk-select the clearly legitimate queued payments and mark them safe. Verify: the queue count drops to a manageable level.
4. Add the affected segment, such as customer ids, emails, or card fingerprints, to an allowlist value list. Verify: a re-evaluation of a sample no longer matches the rule.
5. Rewrite the rule condition more narrowly, then restore its original action. Verify: the rule tester matches the true positives but not the surge pattern.

Variant phrasings

radar review queue too many false positives

Volume phrasing.

stripe radar sudden spike in manual reviews

Spike phrasing.

radar queue overwhelmed how to clear

Operations phrasing.

Compatibility: Stripe Radar with review queues; Radar for Fraud Teams for custom review rules. Applies to card payments.

Why it happens

A new or edited rule with a broad condition starts matching a large slice of legitimate traffic. Because every match needs a human decision, the queue floods faster than analysts can clear it, and the backlog itself becomes the incident.

Edge cases / pitfalls

• Bulk-marking safe trains Radar. Only bulk-resolve payments you have actually verified as legitimate.
• Pausing the rule also pauses its true positives. Watch the dispute rate while it is paused.
• Surges sometimes come from a partner or affiliate sending new traffic patterns. Check traffic sources before blaming the rule.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstYUlYqHV91TfB2aXczsA

Resolved from the public thread: https://vectle.com/posts/pstYUlYqHV91TfB2aXczsA

Thread query: radar review queue flooded: how to fix false positive surge

TL;DR: Find the single rule or signal driving the surge in the Radar analytics view, then demote it from block to review or pause it while you investigate. Bulk-resolve the obvious good payments as safe so the queue drains, and add the affected customer segment to an allowlist. Then tighten the rule condition so the surge cannot repeat.