The evidence trail behind every AdOps rule run

Every AdOps rule run leaves evidence. AdOps writes one batch record per run and one result row per campaign per task, carrying an Executed, Not Executed or Skipped badge, the action’s parameters, each condition’s pass or fail with the value read, before and after values on changes, the execution time and the next scheduled execution.

Why does the log matter more than the feature list?#

Because automation that spends money is only worth running if you can answer two questions afterwards: what did it do, and why. A rules engine without evidence asks you to trust it. A rules engine with per-condition evidence lets you check it, and checking is what makes it safe to widen the rule to more accounts.

The log is also where a rule gets debugged. A threshold that never fires and a threshold that fires on every campaign look identical from the outside. In the log they look completely different, because the actual value the engine read is printed next to the expected value on every condition.

What does a batch record hold?#

Rule Logs lists execution batches with four columns: Execution Time, Ad Account, Applied Items and Affected Tasks. Applied items renders as a badge, and affected tasks renders green when something happened and grey when nothing did, so a month of runs can be scanned in a few seconds.

Behind each row sits a benchmark document keyed on the batch id, carrying the rule, the ad account, the start time, the number of applied items, a running execute count and a status of RUNNING or DONE. The record is written as an upsert on the batch id, so a job that the queue redelivers reuses the same row rather than leaving duplicate half-finished audit lines.

Beside the table, a Rule details card shows the rule name, its list of actions, its schedule rendered either as a run interval or a per-day timetable, and who last updated it.

What does the detail view show per campaign?#

Opening a batch shows every campaign it evaluated. For each campaign, one card per task.

The card header carries the action icon and label, one of three badges, and the timing. Executed means the action ran. Not Executed means the conditions did not pass. Skipped means a cooldown blocked the evaluation before it began.

The card body has two columns.

Action Details prints the parameters the action actually used. For a name action that is the mode, the separator and the text. For a budget action that is the increase value, the maximum budget cap and the value type. For a replace action it is the find text and the replacement. Below them sit the level badge, the ad account and the executed-at time.

Condition Evaluations prints each condition as the metric label with its reporting period, a green Pass or red Fail badge, and the sentence Actual value, operator, Expected value. Where the condition used a custom metric, AdOps resolves the stored id back into the metric’s real name, so the log reads in the language you named things in rather than as a database id.

When an action changed something, a Value Changes block shows Before in red and After in green. Budget and name actions record this pair; the three lifecycle actions record the status they wrote rather than a before and after.

How do you find a run that was slow?#

Every result carries a total execution time, colour graded in the detail view: green under 5 seconds, amber from 5, red past 10. Administrators additionally see an Execution Steps timeline, a numbered list of the internal stages with the elapsed seconds and a pass or fail chip for each.

Four step names appear: the skipped marker written when a cooldown blocked the run, the batched Meta Insights fetch, one entry per condition calculation, and the final condition check. Reading that list tells you whether a slow run was slow because Meta was slow or because the rule asked for too much.

The Benchmark page collects both angles. A Queue Progress tab lists batches in flight with start date, rule name, ad account and a progress bar reading executed against total. A Slow Rule tab filters executions by a minimum execution time, defaulting to 10 seconds, over a date range, and prints per-execution timing, the initial and new values of the action, the per-step breakdown in seconds and every condition’s pass or fail.

What if you only want to see what changed?#

Use the Activity Log. It returns only results where an action really ran, enriched with the rule name, an event name combining the action and the level, the affected campaign as an ID and name badge, and the time of the change. A six-field filter panel narrows it by event name, ad account, rule name, entity ID, entity name and action, and the filter pill shows a dot whenever a filter is active.

Clicking a row opens the same evidence in a modal: the affected campaign, the rule, the action, the ad account, the time, and each condition’s pass or fail with the value read, plus a link into the full logs.