AdOps gates a rule on the clock with two metrics: Time greater than and Time less than. Each carries a 24-hour picker running from 12:00 AM to 11:00 PM and a Sunday-first day-of-week multi-select, and they are the only two metrics in AdOps that accept weekdays. Neither takes a lookback period, because both describe the present moment rather than a window.
What can a time condition actually express?
A single hour bound, plus the days it applies to. Combine two of them in one task and you have a window:
Time greater than09:00, days Monday to FridayTime less than21:00, days Monday to Friday- task operator AND
Both conditions sit next to your performance conditions in the same task, so the action only fires when the metric test and the clock test are both true. That is the whole mechanism, and its simplicity is the point: the rule stays readable in the log, where each condition prints its own Pass or Fail.
Why does the hour you pick include itself?
Because both comparisons are inclusive on the boundary hour. Time greater than fails only when the current hour is below the hour you named; Time less than fails only when the current hour is above it. The named hour always passes on both sides.
The practical consequence is worth writing on a sticky note. A window of Time greater than 09:00 AND Time less than 21:00 is open from 09:00:00 to 21:59:59 — fourteen hours, not twelve. If you want the window to close at nine in the evening, name 20:00 as the upper bound.
The same applies to a single-sided rule. Time greater than 22:00 starts at 22:00 exactly, not at 23:00.
Should dayparting live in the schedule or in the conditions?
Both exist, and they solve different problems.
| Timetable schedule | Time conditions | |
|---|---|---|
| What it controls | Whether the rule wakes up at all | Whether the action fires when it wakes |
| Granularity | A 7-day by 24-hour grid you click | An hour bound plus selected weekdays, per condition |
| Visible in the log | As the rule’s schedule | As a Pass or Fail on each run |
| Best for | A rule that only makes sense at one time, such as a nightly reset | A rule that must run often but only act inside a window |
A rule that raises budgets when ROAS is strong should run on a short interval and carry time conditions, because you want it evaluating all day and acting only during hours you trust. A rule that resets budgets at 23:00 should live on the timetable, because there is no reason for it to wake up 90 times a day.
One mechanical note on the timetable: when no slot remains today, AdOps scans forward day by day for the next slot, up to seven days ahead. A timetable with a single Sunday slot therefore schedules a week out, which is correct but surprising the first time you see the Next Scheduled Execution timestamp.
How do you write a night budget reset?
The shape most Indonesian advertisers want is: spend hard during the hours that convert, pull budgets back overnight, restore them in the morning. That is two rules, or one rule with two tasks and opposite time conditions.
Task 1 — Decrease budget. Conditions: Time greater than 23:00, all seven days. Action: decrease budget by a percentage, with the Minimum budget cap filled in so the reduction cannot floor a campaign. Action frequency: once a day.
Task 2 — Increase budget. Conditions: Time greater than 07:00 AND Time less than 08:00, all seven days. Action: increase budget, with the Maximum budget cap filled in. Action frequency: once a day.
Three details make this behave.
The three budget actions re-read the live daily budget from Meta immediately before writing, so a percentage change applies to the campaign’s actual current budget rather than to whatever AdOps last saw. The once-a-day cooldown is what keeps a rule on a 15-minute interval from applying the same decrease repeatedly across the hour it is true. And the caps matter in opposite directions: a maximum on the increase, a minimum on the decrease.
If the morning restore must land on an exact figure rather than a percentage, use set budget instead — it accepts a literal amount or a custom metric, and has no percentage mode. Pairing it with a custom metric backed by a Google Sheet gives you a per-campaign daytime budget table you can edit without touching the rule. The shipped Night Budget Reset template is a working version of this pattern to start from.
Which clock is the rule reading?
AdOps has no per-rule time zone field, so a time condition is evaluated against the clock of the engine that runs it. Do not assume; verify.
The check takes one day. Set the rule live with a narrow window, then open Rule Logs and read the Execution Time column on the first batch, plus the Pass or Fail on the time condition in the batch detail. If the window is landing an hour or several hours away from where you expected, shift the hour bound rather than arguing with the clock. Then write the offset into the rule name, so the next person to open it does not repeat the investigation.
What does dayparting not fix?
It does not find your hours for you. AdOps does not report an hour-of-day breakdown, so the curve has to come from Meta’s own reporting; AdOps is where you express the decision once you have it.
It also does not make a thin hour profitable. Cutting spend between midnight and 06:00 is only a win if that window genuinely underperforms in your account, and the honest test is a fortnight of data rather than a rule of thumb from another market. Payday weeks, long holidays and Ramadan all bend the curve differently for different categories, which is exactly why the answer has to come from your account and not from a blog post.
Start with one window, one metric condition and one action. Read a week of logs. Then widen.
