# Reading execution logs

> How Rule Logs, the log detail view and the Activity Log record what a rule did, and how to read the evidence.

Source: https://adops.id/docs/reading-execution-logs/
Last updated: 2026-08-20
Publisher: AdOps (https://adops.id) — an independent product, not affiliated with Meta Platforms, Inc.

---

## Key facts

- **Execution badges:** Executed, Not Executed, Skipped
- **Rule Logs columns:** 4 (Execution Time, Ad Account, Applied Items, Affected Tasks)
- **Evidence per condition:** Pass or Fail plus the actual value (shown as "Actual <value> <operator> Expected <value>")
- **Slow-run colouring:** over 10 seconds is red (over 5 seconds is amber in the log detail)
- **Log cleanup:** daily at 00:00 (execution results older than 3 days are removed)

Every AdOps run writes two things: one batch record for the run, and one result per campaign per task. The Rule Logs page lists the batches, the batch detail shows each campaign's tasks with an Executed, Not Executed or Skipped badge, and every condition is stored with the actual value the engine read and a Pass or Fail badge.

## Opening the log for a rule

From the Rule List, open a rule's three-dot menu and choose **Logs**. The page is headed **Rule Logs** with a back arrow to the rule.

The table has four columns — **Execution Time**, **Ad Account**, **Applied Items** and **Affected Tasks**. Applied items render as a blue badge; affected tasks render green when the count is above zero and grey when it is zero. The whole row is a link into that batch. When there is nothing yet the page reads **No rule logs found**.

On the right, a **Rule details** card repeats what the rule is: its name linking back to the editor, **Actions in rule: N** with the action list beneath, a Schedule section reading either "Runs every N minutes" or the per-day timetable from Sun to Sat, and **Updated by `<user>` (`<time ago>`)**.

Selecting log rows raises a bulk bar with **Delete Selected**.

## Reading a batch

Clicking a row opens the batch. A summary card names the **Rule Name**, the **Batch ID** and the **Applied Items** count.

Below it, each campaign gets a block: the campaign name and `ID: <campaign_id>` on the left, and one card per task on the right. The task card header carries the action icon and label, the execution badge, and either **Next Execute: `<date>`** or **Execution Time: `<n>s`** followed by **Next: `<date>`**. Execution time is colour-graded — amber above 5 seconds, red above 10.

The card body has two columns.

**Action Details** lists the parameters that action ran with — Mode, Separator and Text for Add to name; Increase Value, Max Budget Cap and Type for a budget action; Remove Text; Find Text and Replace With — plus a Level badge, the Ad Account and Executed At.

**Condition Evaluations** lists every condition with its metric label and period, a green **Pass** or red **Fail** badge, and the comparison written out: **Actual `<value>` `<operator>` Expected `<value>`**. This is the answer to "why did this campaign get paused?" — the number in Actual is the number the engine saw at that moment.

When an action changed something, a **Value Changes** block shows **Before** in red and **After** in green.

If you have the ADMIN role, the detail also renders an **Execution Steps** timeline: numbered steps with a name, a message, the elapsed seconds and a Pass or Fail chip on the metric evaluated.

An empty batch shows **No execution logs found** with a **Back to Logs** button.

## The three badges

**Executed** — the conditions passed and AdOps called Meta.

**Not Executed** — the task was evaluated and at least one condition failed. Read the Condition Evaluations column to see which.

**Skipped** — the task was not evaluated because its action frequency cooldown had not elapsed. The result carries the reason `next_execute_not_reached` and the time the task becomes eligible again, so a quiet rule is explained rather than mysterious.

## The Activity Log

Where Rule Logs is scoped to one rule, the **Activity Log** is one chronological feed across every rule, and it lists only actions that actually executed. Columns are Event, Affected item, Rule and a relative timestamp; the affected item is a campaign badge with its id and name, and the rule links to its editor.

A **Filters** pill expands six fields — Event Name, Ad Account, Rule Name, Entity ID, Entity Name and Action — with **Apply** and **Reset**, and shows a dot badge while any filter is active. Clicking a row opens a modal listing the Affected Campaign, Rule, Action, Ad Account and Time, plus a **Rule Conditions:** list with each condition's operator, target and "Current: `<value>`", footed by an **Open Logs** button.

## When a run was slow

The **Benchmark** page has two tabs. **Queue Progress** lists in-flight batches with their start time, rule, ad account and a "Progress: executed/total" bar. **Slow Rule** filters executions by a Minimum Time in seconds (the field defaults to 10) and a date range of Today, Yesterday, Last 7 days or Last 30 days, then prints the per-step timing breakdown and every condition's Pass or Fail for each slow execution.

## Keeping evidence

A cleanup job runs daily at midnight and removes execution results older than 3 days, and you can clear a rule's logs yourself — the confirmation reads "Clear All Logs?". Export anything a client or an audit will need before it ages out.