POST /api/v1/rules/preview. Runs rule logic without acting. Shows evaluated / matched / skipped entities with metric values + reasons.

Preview (dry-run) — test before activating

Preview button in the rule builder + on /rules/:id. Backed by POST /api/v1/rules/preview (verified). Runs the rule's evaluation logic against current data without triggering any action. Returns the list of entities evaluated, which matched, which were skipped, and why. Mandatory step before activating a new rule.

Who is this for

Anyone building a new rule. Also: anyone changing scope / conditions of an existing rule before saving.

Why preview matters

The rule builder lets you write any combination of scope + conditions + actions. Without preview, you'd activate and only learn after the first fire whether:

• The scope catches the right entities
• The conditions match the entities you intended
• Skips (cooldown, daily cap) would block expected actions

Preview surfaces all of this in seconds, with no risk.

How to preview

In the builder (new rule)

1. Build the rule (steps 1-9 per rul-102)
2. Before clicking Save: click Preview
3. Modal opens with results

On existing rules

1. Open /rules/:id
2. Top toolbar → Preview
3. Same modal opens

You can preview a rule in paused or active status — preview doesn't change anything.

What preview returns

POST /api/v1/rules/preview returns a JSON shape:

• entities_evaluated — total entities scanned in scope (number)
• entities_matched — entities passing all conditions (array with per-entity metric values + which conditions triggered)
• entities_skipped — entities matching conditions but skipped due to a protection (array with per-entity skip reason)
• entities_errored — entities where evaluation failed (e.g. missing metric for that platform)

In the UI, results render as a table:

Reading the results

Empty entities_evaluated

Scope returns nothing. Common causes:

• Wrong ad account selected
• name_contains typo
• status_in: [active] but all entities are paused
• Entity level mismatch (entities are adsets but rule targets campaigns)

Fix: re-check scope.

Lots of entities_matched

If 50 entities match: scope or conditions too loose. Tighten one:

• Add spend gt N guard (filter out low-volume)
• Tighten thresholds
• Add name_contains filter

Lots of entities_skipped

Most common reasons (real values):

• cooldown — entity acted on recently (by this rule)
• failure_backoff — 5+ consecutive failures for the entity in 24h
• pending — in-flight action in the 30-min window
• no_tokens — no valid platform token for the entity's account
• redundant_action — entity is already in the action's target state

Often expected. Skip reasons are informational.

Note: max_executions_per_day isn't a per-entity skip reason — once the rule hits its daily cap it stops evaluating for the rest of the UTC day.

entities_errored

Usually missing data:

• Metric not available on the platform (e.g. frequency on Google in some contexts)
• Time range has no data (very new account)
• Postback metric not yet seeded

Worked example

Building "Kill losers — CPA > 30 / 7d, adset level, ClientA only":

ad_account_ids: [act_clientA]entity_filter: {name_contains: "ClientA", status_in: [active]}entity_level: adsetcondition_logic: ANDconditions:  - {metric: cpa, operator: gt, value: 30, time_range: last_7d}  - {metric: spend, operator: gt, value: 50, time_range: last_7d}actions: [pause]cooldown_minutes: 360max_executions_per_day: 5

Preview returns:

• evaluated: 42 adsets
• matched: 4 (with CPA values 35, 38, 42, 55 + spend > 50)
• skipped: 0
• errored: 0

Result is reasonable. Activate.

Vs the same rule with spend gt 5 (instead of 50):

• evaluated: 42
• matched: 18 — including low-spend tests where CPA is misleading (1 conversion in $10 spend)

Tighten the spend guard back. Re-preview. Then activate.

Preview vs first real fire

Preview uses the current metric snapshot. Real fire uses metrics at the time of the cron tick (within 15 min of preview, in practice). Small drift is expected.

Preview does NOT consume from max_executions_per_day counter. You can preview unlimited times.

Best practice workflow

1. Build draft
2. Preview
3. Adjust scope / conditions
4. Preview again
5. Repeat until matches make sense
6. Save (status remains paused)
7. Optional: temporarily change action to notify_only for first 24-48h of active status
8. Validate notifications match expected entities
9. Switch action back to pause / increase_budget_pct / etc.

This "preview → notify_only → real action" ramp catches both logic bugs and unexpected real-world behavior.

Common mistakes

• Skipping preview: rule activates against wrong scope → unexpected actions on production campaigns
• Previewing only happy path: also preview at edge times (end of week, after weekend) where metrics behave differently
• Ignoring entities_skipped: high skip count often means rule won't act much in practice — adjust cooldown or daily cap

FAQ

What does Wevion's rule preview do?

Preview, backed by POST /api/v1/rules/preview, runs a rule's evaluation logic against current data without triggering any action. It returns the entities evaluated, which matched, which were skipped and why, plus per-entity metric values. It's a mandatory step before activating a new rule and carries no risk.

Does preview count against my daily execution limit?

No. Preview does not consume from the max_executions_per_day counter, so you can preview unlimited times. It uses the current metric snapshot, while a real fire uses metrics at the cron tick (within about 15 minutes of preview), so small drift is expected. You can preview rules in paused or active status.

Why does preview return no entities?

An empty entities_evaluated means scope returns nothing. Common causes in Wevion: wrong ad account selected, a name_contains typo, status_in: [active] while all entities are paused, or an entity-level mismatch (entities are adsets but the rule targets campaigns). Re-check the scope.

What if too many entities match in preview?

If many entities match, your scope or conditions are too loose. Tighten by adding a spend gt N guard to filter out low-volume entities, tightening thresholds, or adding a name_contains filter. Low-spend tests can show misleading metrics, like a CPA based on one conversion in $10 of spend.

What's the recommended workflow before activating a rule?

Build a draft, preview, adjust scope and conditions, then preview again until matches make sense. Save (status stays paused). Optionally set the action to notify_only for the first 24-48 hours of active status, validate the notifications, then switch back to the real action. This ramp catches logic bugs and unexpected behavior.

FAQ

What does Wevion's rule preview do?

Preview, backed by POST /api/v1/rules/preview, runs a rule's evaluation logic against current data without triggering any action. It returns the entities evaluated, which matched, which were skipped and why, plus per-entity metric values. It's a mandatory step before activating a new rule and carries no risk.

Does preview count against my daily execution limit?

No. Preview does not consume from the maxexecutionsper_day counter, so you can preview unlimited times. It uses the current metric snapshot, while a real fire uses metrics at the cron tick (within about 15 minutes of preview), so small drift is expected. You can preview rules in paused or active status.

Why does preview return no entities?

An empty entitiesevaluated means scope returns nothing. Common causes in Wevion: wrong ad account selected, a namecontains typo, status_in: [active] while all entities are paused, or an entity-level mismatch (entities are adsets but the rule targets campaigns). Re-check the scope.

What if too many entities match in preview?

If many entities match, your scope or conditions are too loose. Tighten by adding a spend gt N guard to filter out low-volume entities, tightening thresholds, or adding a name_contains filter. Low-spend tests can show misleading metrics, like a CPA based on one conversion in $10 of spend.

What's the recommended workflow before activating a rule?

Build a draft, preview, adjust scope and conditions, then preview again until matches make sense. Save (status stays paused). Optionally set the action to notify_only for the first 24-48 hours of active status, validate the notifications, then switch back to the real action. This ramp catches logic bugs and unexpected behavior.

Steps

1. Build the rule (steps 1-9 per rul-102)
2. Before clicking Save: click Preview
3. Modal opens with results

Last updated: 2026-05-17

Related articles

• Create your first rule — step-by-step
• Rules — best practices for scaling and protecting
• Rules troubleshooting