Reading execution logs

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.