Schedule, guards and priorities
This article covers when the rule checks objects, what prevents it from acting too often or on top of a buyer's manual work, and who wins if several rules target the same object. The settings are on the “Schedule” and “Guards and notifications” steps of the builder; the priority is on the “Name and ad accounts” step.
Schedule: how often the rule checks objects
Frequency | How it works | What it is good for |
|---|---|---|
Every N minutes: 15, 30, 60 (every hour), 180 (every 3 hours), 360 (every 6 hours), 1440 (once a day) | The rule runs for an ad account if at least N minutes have passed since the previous run for that ad account | Stop-losses — 15–30 minutes; budgets — once an hour; trend notifications — once every 3 hours |
Daily | Runs at set times of day (up to 24 times), by ad account time | A daily check at a fixed time, for example at 10:00 |
At set hours | Same as “Daily”, but you select a list of hours, for example 09:00, 13:00, 17:00 | Several checks during working hours |
What you should know:
A new rule is created with the “Every hour” frequency and no active windows.
The scheduler checks rules every 5 minutes, so the actual run may happen a few minutes later than scheduled. With a large queue of ad accounts (up to 50 ad accounts are processed per pass), even later.
“Once a day” (1440 minutes) is not tied to a time of day: the next run happens 24 hours after the previous one. If you need a run at a specific time, choose “Daily”.
Missed time is not made up. If the system was down for three hours, an hourly rule runs once, not three times. The decision is made on fresh data anyway, and a series of back-to-back runs would add nothing.
The schedule is calculated separately for each ad account of the rule.
Active windows
Active windows limit the days and hours when the rule can run at all. With no windows, the rule runs around the clock (“No windows: the rule runs around the clock.”).
A window is a set of weekdays (Mon–Sun) and a “from — to” time range. The end of a window is not included: the 06:00–18:00 window closes exactly at 18:00. “24:00” is the end of the day.
A window cannot cross midnight. A night interval is set with two windows: for example, “22:00–24:00” and “00:00–06:00”.
Windows of the same day must not overlap — otherwise “Active windows overlap”.
A window cannot be empty (“from” must be earlier than “to”) — otherwise “Active window is empty”.
For “Daily” and “At set hours”, each run time must fall within a window — otherwise “Run time is outside the active windows”.
Up to 28 windows in total. A new window in the builder is created as “weekdays, 06:00–24:00”.
How windows combine with frequency:
Every N minutes: outside a window the rule does not run; inside it runs at the set interval. When a window opens, the first run happens at the nearest scheduler check.
Daily / at set hours: a time outside the window of its day does not fire at all. For example, with a Mon–Fri window, 09:00 on Sunday does not fire and is not “caught up” on Monday. A time at the very end of a window (for example, 17:57 with a window until 18:00) is executed even if the scheduler reached the rule a couple of minutes after the window closed.
Example: scale only from 00:00 to 18:00, stop-loss around the clock
Goal: scale profitable ad sets only in the first half of the day by ad account time, so that Facebook has time to spend the new budget, and keep the stop-loss on at all times.
Rule | Frequency | Active windows | Action |
|---|---|---|---|
“Ad set scaling” | Every hour | Mon–Sun, 00:00–18:00 | Daily budget +20 %, not above 300 |
“Stop-loss” | Every 30 minutes | None (around the clock) | Pause until end of day |
At 10:00 both rules run. If both fire on the same ad set, the pause wins — it always beats a budget increase.
At 19:00 scaling does not run; the stop-loss keeps watching the spend.
At 00:00 the scaling window opens again, and the rule runs at the nearest check.
Tip. If scaling looks at “yesterday” or “N full days” by cohort, start the window at 06:00 rather than 00:00: in the first hours of the day, deposits from yesterday evening's clicks are still coming in, and yesterday's ROI is understated. This is how the “Scale profitable” and “Cut unprofitable” templates are set up — their window is 06:00–24:00.
Example: night only
A CPM spike notification is needed only at night, when nobody is watching the ad account. Windows: “Mon–Sun, 22:00–24:00” and “Mon–Sun, 00:00–06:00”, frequency “Every hour”.
Example: weekdays during working hours only
Window “Mon–Fri, 09:00–21:00”, frequency “Daily” at 10:00 and 16:00. The rule does not run on weekends.
Time zone — each ad account has its own
A rule has no time zone of its own. The schedule, active windows, “today” and “yesterday” in conditions, the day for the action limit and enabling at 00:00 are calculated in the time zone of each ad account separately. The builder shows the time zones of the selected ad accounts at the “Schedule” step.
Example. A rule with a 00:00–18:00 window on two ad accounts: Europe/Kyiv and America/New_York. In the Kyiv ad account the window opens at midnight Kyiv time, in the New York one — at midnight New York time, that is, several hours later. Each ad account lives by its own clock.
Guards
Guards are calculated per “rule — object” pair: actions of other rules do not use up this rule's limits.
Guard | Default | Range | What it does | What the log shows |
|---|---|---|---|---|
Pause after an action (cooldown) | 24 h | 0–720 h | After any action of the rule on an object (including a notification), the rule does not touch this object for the set time | “Skipped: cooldown” — “Cooldown after the previous action” |
Actions per object a day | 2 | 1–48 | No more than N rule actions on one object per ad account day; notifications count too | “Skipped: daily limit” — “Daily action limit reached” |
Pause after a manual change | 24 h | 0–720 h | After a manual status change the rule does not change the object status; after a manual budget change, the budget | “Skipped: recent manual change” — “Recent manual status change” or “…budget change” |
Allowed data lag | 90 min | 15–1440 min | If spend or conversion data is older, the run for the ad account is skipped entirely | The run is “Skipped: stale data” with a reason |
Ad account budget cap | Off (1000 when enabled) | Greater than 0, in the ad account currency | The total daily budget of the ad account's active CBO campaigns and ABO ad sets after the action will not exceed the cap | “Skipped: ad account budget cap” |
Pause after an action
Counted in regular hours from the moment of the action and runs past midnight: a 12-hour pause after an action at 20:00 ends at 08:00.
Applies to all rule actions on the object, including notifications — otherwise a message would arrive on every run while the condition holds.
The exception is a rule with a pause until end of day: its cooldown ends no later than the re-enabling at 00:00, so that in the morning the rule watches the object again. The re-enabling at 00:00 itself does not start a cooldown.
If Facebook has not yet confirmed the result of the previous action, the rule does not repeat the action on the same data: “Skipped: cooldown” with the reason “The previous action is not confirmed yet”.
Example. A scale rule “+20 % if yesterday's ROI is above 50 %” runs every hour, with a 24-hour pause. The budget was raised on Monday at 07:00 — the next increase for this ad set is possible no earlier than Tuesday 07:00. Without the pause, the rule would raise the budget every hour until yesterday's ROI changes.
Actions per object a day
The day follows the ad account time zone; the counter resets at 00:00 ad account time.
Notifications count; the system re-enabling at 00:00 does not.
Works together with the pause: the pause sets the interval between actions, the limit sets the daily ceiling.
Example. A rule “Notify if CPI over 24 hours is above $3” with a 4-hour pause and a limit of 2: even if CPI stays high all day, no more than two notifications per day arrive for one ad set.
Pause after a manual change
A manual change is a change in Facebook or Ads Manager, a change by a user in Adset.pro, or a rollback of a rule action in the log. Changes made by autorules are not considered manual.
The guard is split by field: after a manual status change the rule does not touch the status but can change the budget; after a manual budget change, the other way around.
Notifications are not subject to this guard.
A value of 0 means do not wait. But even with 0, the rule never enables an object that a person turned off (see below).
Example. A stop-loss paused an ad set until end of day at 14:00. The buyer sees that deposits are just delayed and enables the ad set in Ads Manager at 15:00. The stop-loss has a pause of 0, and without this guard it would turn the ad set off on the next run at 15:30. With a 24-hour pause after a manual change, the rule will not touch the ad set status until 15:00 the next day.
Allowed data lag
Before each run, the rule checks how fresh the Facebook spend and tracker conversion data for the ad account is. If it is older than the threshold, the run is skipped entirely — it is better not to act than to act on outdated spend.
Skip reasons shown in the log: “No profile syncs this ad account”, “Facebook sync failed on every profile”, “Facebook spend has not been synced yet”, “Facebook spend sync is behind”, “Tracker conversion freshness is unknown”, “Tracker conversions are behind”.
To learn about such skips right away, enable the “Stale data” event in “Notify about” (by default only “Actions” and “Errors” are enabled).
Tip. For a stop-loss, keep the threshold at 60–90 minutes: a “spent without deposits” decision based on three-hour-old spend is more dangerous than a skip. For rules with “yesterday” and “N full days” windows, the threshold can be raised.
Ad account budget cap
A ceiling on the total daily budget of all active CBO campaigns and ABO ad sets of the ad account. It is checked when a daily budget is increased and when an object is enabled by a rule that has a cap set. If there is less room than the action requests, the increase is cut to the remainder; if there is no room, the action is skipped. A detailed example is in the article “Actions”.
Important. The cap is set in the rule and applies only to its actions. It does not restrain manual increases or rules without a cap. If several scale rules run on one ad account, set the cap in each of them.
Rule priorities and conflicts
The priority is set at the “Name and ad accounts” step: a number from 1 to 100, 50 by default. The hint in the builder: “when rules of one ad account conflict, the higher priority wins; a pause always beats a budget increase”.
Rules of one ad account that are due to run are processed together, and conflicts between them are resolved as follows:
A pause is the strongest. A pause beats enabling and a budget increase regardless of priority.
A permanent pause beats a pause until end of day — even if the rule with the pause until end of day has a higher priority. Otherwise the object would be enabled at 00:00 against the rule that wanted to turn it off for good.
Then by priority. The object status is changed by one rule — the one with the higher priority. The object budget (each budget type) is also changed by one rule — the one with the higher priority.
Whoever takes the status takes the object. If a higher-priority rule pauses or enables the object, budget actions of lower-priority rules on this object are skipped.
With equal priority the rule created earlier wins.
Skipped actions do not interfere. An action rejected by a guard or a limit does not take the object: for example, a pause waiting for the cooldown to end does not block another rule's budget increase.
Notifications do not conflict with anything.
Test rules do not interfere with live ones. A rule in Dry-run mode takes nothing. Its simulation is calculated together with all live rules of the ad account, so the test log shows what would happen taking the live rules into account. Test rules do not conflict with each other.
In the log, the losing action is marked “Skipped: conflict with another rule” with a reason and the link “Won by rule …”.
Scenarios: rule A (priority 80) and rule B (priority 30) on one ad set
Rule A (80) | Rule B (30) | What happens | Reason for the loser |
|---|---|---|---|
Budget +20 % | Pause | B's pause | A: “A pause wins over this action” |
Pause until end of day | Pause (permanent) | B's permanent pause, no re-enabling at 00:00 | A: “Another rule pauses the object permanently” |
Pause | Pause | A's pause | B: “Status is changed by a higher-priority rule” |
Daily budget +20 % | Daily budget −30 % | A's increase | B: “Budget is changed by a higher-priority rule” |
Daily budget −30 % | Pause | Both: pause and budget decrease | — |
Pause | Daily budget −30 % | Only A's pause | B: “Object is paused or enabled by a higher-priority rule” |
Enable | Budget +20 % | Only A's enabling | B: “Object is paused or enabled by a higher-priority rule” |
Enable | Pause | B's pause | A: “A pause wins over this action” |
Pause, but the object is still in the cooldown after an action | Budget +20 % | B's increase | A: “Skipped: cooldown” |
Notify | Pause | Both: pause and notification | — |
Pause, Dry-run mode | Budget +20 %, Live mode | B's increase is executed in Facebook; A's log shows “Simulated (dry-run)” — in live, the pause would have won | — |
Budget +20 %, priority 50, created earlier | Budget −30 %, priority 50 | A's increase | B: “Budget is changed by a higher-priority rule” |
Important. Conflicts are resolved between rules that run for the ad account in the same run. If the rules have different schedules, each acts in its own run: scaling raises the budget at 10:00, and the stop-loss at 10:30 still pauses the ad set. The pause after an action and the daily action limit protect against “ping-pong” between rules.
Tip. Set priorities deliberately: high (80–100) for stop-losses and kill rules, medium (50) for scaling, any for notifications. Then, whenever schedules coincide, the protective rules take precedence.
Manual changes in Ads Manager: how the rule respects them
The buyer always takes precedence over the rule. Here is what the rule does to avoid overwriting manual work:
It does not enable what a person turned off. The “Active” action enables an object only if the last status change was made by an autorule. If the object was turned off in Ads Manager, in Adset.pro or by a rollback, the result is “Skipped: recent manual change” with the reason “Status was changed manually”. Waiting does not help here: the rule never enables such an object until some rule turns it off again.
It waits after a manual edit. Pause after a manual change (24 hours by default) — separately for status and budget.
It checks Facebook before making a change. If the status or budget changed between the rule's decision and sending the change, the action is skipped: “Skipped: object changed” (“Status changed after the decision” or “Budget changed after the decision”).
It does not re-enable at 00:00 what a person touched. If an object paused until end of day was manually changed or edited in Facebook after the pause, the re-enabling at 00:00 is cancelled, and the rule owner receives a notification.
It does not roll back over other changes. A rollback of an action in the log is rejected if the object was changed by a person or another rule after the action.
It takes manual increases into account in the growth limit. The daily growth limit is calculated from the budget at the start of the day: if the buyer has already raised the budget manually above the ceiling, the rule will not increase it.
The rule learns about manual changes from the ad account sync. A change made in Ads Manager between the sync and the rule action is caught by the check against Facebook before sending.
Tip. If you often edit budgets manually in the first half of the day and the rule scales in the mornings, increase the pause after a manual change or shift the rule's active window so they do not interfere with each other.