Timeline of rule fires with evaluated / matched / acted / skipped / errored counts + per-entity details + metric snapshots.

Execution history and audit

/rules/:id. Every evaluation that matched at least one entity is recorded in the rule's execution history, with full per-entity outcomes. Rule lifecycle entries (rule.create / rule.delete / rule.toggle / rule.duplicate, dot-notation) live separately in the audit log. Use both to answer "what did this rule do and when?".

Who is this for

Rule owners auditing what rules actually did. Anyone debugging "why did this campaign get paused yesterday?". Admins on compliance reviews.

How to view

Per-rule execution timeline

1. Open /rules/:id
2. Scroll to Executions section
3. Timeline shows fires in reverse-chronological order
4. Click a fire → expanded view per entity

Per-rule audit log

Same page → Audit tab. Shows lifecycle entries: who created / edited / paused / duplicated the rule and when.

What's in an execution record

automation_rule_execution schema fields:

• id
• rule_id
• status — one of evaluated / executed / skipped / error
• entities_evaluated — total scanned
• entities_matched — passed all conditions
• entities_acted — action successfully applied
• entities_skipped — matched but skipped by a protection
• entities_errored — execution failed (API error / validation)
• details (JSON) — per-entity result map
• error_message — top-level failure (e.g. SQS timeout)
• started_at, completed_at, duration_ms
• metrics_snapshot (JSON) — the metric values used for evaluation

Reading the details

For each entity in details:

{  "entity_id": "120211211211",  "entity_name": "Adset Prospecting US v3",  "matched": true,  "metric_values": {"roas": 1.2, "spend": 120},  "action_applied": "pause",  "before": {"status": "active"},  "after": {"status": "paused"},  "skipped": false}

Skipped entries include a skip reason (real values):

• cooldown
• failure_backoff
• pending
• no_tokens
• redundant_action

Errored entries include the error detail.

metrics_snapshot

A JSON object of the metric values seen at evaluation time. Useful when:

• Investigating "the dashboard shows ROAS 2.5 now — why did the rule pause the adset?" → check snapshot; rule saw ROAS 0.8 at fire time, late conversions raised it
• Debugging condition logic — did the metric actually match?

Audit log entries

The audit log records rule lifecycle actions (dot-notation):

There is no rule.update audit action and no per-execution audit action — individual rule fires are recorded in automation_rule_execution, not the audit log.

Access it from the audit log.

Paging executions

The execution history is paginated only — it does not support date, status, or min-acted filters. Executions are shown in reverse-chronological order, a page at a time (up to 100 per page, 20 by default).

Use cases

Why did this adset pause yesterday?

1. Open the adset in Ads Manager → see status changed at 14:35
2. Go to /rules → find the rule that matches the adset's scope
3. Open /rules/:id → executions around 14:30-14:40
4. Find the entity in details → see metric_values + match details
5. Validate the rule did the right thing (or fix the rule if not)

Did the new template actually act?

1. After activating a templated rule, check executions over 24h
2. entities_acted > 0 confirms the rule fired action
3. entities_skipped reasons tell you about protection behavior

Compliance audit

1. The audit log (rule lifecycle actions with user attribution)
2. Filter to rule actions (rule.create, rule.delete, rule.toggle, rule.duplicate)
3. Export for compliance review

Retention

Execution history retained per workspace plan tier — see /settings/team/billing. Audit log retention typically matches (or exceeds) execution retention.

Common mistakes

• Looking at the dashboard instead of metrics_snapshot: dashboard is current; snapshot is what the rule saw. They can differ.
• Confusing entities_matched with entities_acted: matched = passed conditions; acted = action actually applied (skip protections aside).
• Missing audit log permission: audit log access may be admin-only depending on workspace policy.

FAQ

Where can I see what a Wevion rule actually did?

Open /rules/:id and scroll to the Executions section. It shows fires in reverse-chronological order with counts for entities evaluated, matched, acted, skipped, and errored. Click a fire to expand per-entity details, including metric values and before/after states.

What is metrics_snapshot and why does it differ from the dashboard?

metrics_snapshot is a JSON record of the metric values the rule saw at evaluation time, while the dashboard shows current values. They can differ — the rule may have seen ROAS 0.8 at fire time while late conversions later raised it to 2.5. Check the snapshot to understand why a rule acted.

What's the difference between entities_matched and entities_acted?

In Wevion, entities_matched are entities that passed all conditions, while entities_acted are those where the action was actually applied. The gap is caused by protections that skip matched entities, with reasons like cooldown, failure_backoff, pending, no_tokens, and redundant_action. Confusing the two is a common mistake.

How do I run a compliance audit of rule changes?

Use the audit log. It records rule lifecycle actions — rule.create, rule.delete, rule.toggle, rule.duplicate (there is no rule.update action) — with user attribution and timestamp, which you can export for review. Individual rule fires are not audit-log actions; they live in the rule's execution history.

How long is execution history retained?

Execution history is retained per workspace plan tier — check /settings/team/billing for your tier. Audit log retention typically matches or exceeds execution retention. The two live in separate tables: executions in automation_rule_execution and lifecycle actions in audit_log.

Related articles

• Rule notifications — get alerted when actions fire
• Rules troubleshooting
• Ads Manager troubleshooting
• Automating ad management with rules — complete guide