Rule schedule — when rules run

Rule schedule values include interval, daily, daily_at_time, custom, and day_parting. Cron fires every 15 min underneath.

Written By Salvatore Sinigaglia

Last updated About 5 hours ago

Rule schedule values include interval, daily, daily_at_time, custom, and day_parting. Cron fires every 15 min underneath.

Rule schedule — when rules run

Rules support the current backend schedule values: interval, daily, daily_at_time, custom, and day_parting. Underneath, a cron in apps/backend/src/server.ts fires every 15 minutes (with 2-minute offset). Sub-15-min effective cadence is not supported by design even if older payloads contain smaller interval values.

Who is this for

Anyone choosing how often a rule should evaluate. Reference for the builder's schedule picker.

Schedule types

interval

Rule evaluates every N minutes. Field: interval_minutes.

  • Effective cadence is bounded by the 15-minute cron tick. Verify route validation before documenting hard min/max rejection.

Most common choice. Good for continuous monitoring rules (kill losers, scale winners, protect spend).

daily_at_time

Rule evaluates once per day at a specific time. Current backend validation expects schedule_config.time for this mode.

day_parting

Rule evaluates only during allowed day/hour windows. Requires DayPartingConfig:

  • days_of_week: array of 0-6 (Sun-Sat)
  • hours_of_day: array of 0-23
  • timezone: IANA timezone string
  • type: "day_parting"

Available as part of the Rules Engine extensions. Use case: work-hours delivery, night protection, or time-of-day budget shifts.

Preset day-parting templates available:

  • work — Mon-Fri, 9-18
  • night — all days, 22-5
  • clear — disabled

The underlying cron

Independent of schedule type, a single cron handles all rules:

  1. Fires every 15 minutes with a 2-minute offset (i.e. at HH:02, HH:17, HH:32, HH:47)
  2. Queries automation_rule table for rules where:
    • status = active
    • last_evaluated_at is null OR more than 15 minutes ago (interval rules)
    • For daily_at_time rules: current time matches the schedule
  3. Updates last_evaluated_at = now() for each selected rule before enqueueing (prevents cascade duplicates if cron tick overlaps SQS processing)
  4. Enqueues to SYNC SQS queue (50 max in-flight, 15-min visibility timeout, 20 max attempts, 30s base backoff)

Why 15 min and not faster: protects against runaway rule loops + respects platform API rate limits + post-conversion data settles every 5-15 min.

interval_minutes = 15 vs 30 vs 60

A rule with interval_minutes: 15 evaluates at the next cron tick after 15 min from last_evaluated_at. Cron runs every 15 min, so cadence is exactly 15 min in steady state.

A rule with interval_minutes: 30 evaluates every 30 min (cron skips it on alternate ticks).

A rule with interval_minutes: 60: every hour.

Pick based on:

  • Fast metrics (spend, CTR, frequency) — 15 or 30 min
  • Slow metrics (postback ROAS / CPA) — 60+ min; data doesn't move faster anyway
  • Daily decisions — use daily_at_time instead

Rule timezone

daily_at_time schedules + day-parting use the rule's own timezone field (timezone, default Europe/Rome), not the workspace timezone. Verify the timezone is correct before saving — a wrong timezone means the rule fires at an unexpected local time.

What you'll see

In the rule list /rules:

  • Column Next fire — when the rule will next evaluate (computed from last_evaluated_at + interval_minutes)
  • Column Last fired — last_evaluated_at value

In rule detail /rules/:id:

  • Schedule summary at top: "Every 30 minutes" or "Daily at 09:00 (Europe/Rome)" (the rule's own timezone)
  • Execution timeline showing actual fire times

Schedule + cooldown interaction

Schedule and cooldown are separate concerns:

  • Schedule = when the rule evaluates
  • Cooldown = how long after acting on an entity before re-acting on the same entity

A rule with interval_minutes: 15 and cooldown_minutes: 360 evaluates every 15 min, but won't re-pause the same adset within 6 hours of pausing it. Other entities can still be acted on at next 15-min evaluation.

See rul-108 protections.

Common mistakes

  • Setting interval_minutes below 15: effective execution is still bounded by the 15-minute cron. Verify current API validation before promising a hard rejection.
  • Wrong timezone on daily_at_time: rule fires at wrong wall-clock time. Verify the rule's timezone field first (default Europe/Rome).
  • Expecting real-time reaction: cron is every 15 min minimum. For real-time alerts on critical issues, use Sentry / monitoring outside Wevion.
  • interval_minutes: 1440 with cooldown 720: rule evaluates once per day but cooldown allows multiple actions within the day — possibly confusing. Match cadence to intent.

FAQ

How often can a Wevion rule run?

A cron in Wevion fires every 15 minutes with a 2-minute offset (at HH:02, HH:17, HH:32, HH:47), so 15 minutes is the minimum effective cadence. Sub-15-minute cadence is not supported by design. This protects against runaway rule loops, respects platform API rate limits, and lets post-conversion data settle.

What schedule types does Wevion support?

Wevion rules support interval, daily, daily_at_time, custom, and day_parting. Interval evaluates every N minutes (interval_minutes), daily_at_time runs once per day at a set time, and day-parting restricts evaluation to allowed day/hour windows using days_of_week, hours_of_day, and an IANA timezone.

What timezone do daily and day-parting schedules use?

daily_at_time schedules and day-parting in Wevion use the rule's own timezone field (default Europe/Rome), not the workspace timezone. Verify it's correct before saving — a wrong timezone means the rule fires at an unexpected local time. The rule detail shows a summary such as "Daily at 09:00 (Europe/Rome)".

What's the difference between schedule and cooldown?

In Wevion, schedule controls when a rule evaluates, while cooldown controls how long after acting on an entity before re-acting on that same entity. A rule with interval_minutes: 15 and cooldown_minutes: 360 evaluates every 15 minutes but won't re-pause the same adset within 6 hours; other entities can still be acted on.

Why doesn't setting interval_minutes below 15 make my rule faster?

Effective execution is bounded by Wevion's 15-minute cron tick, so values below 15 don't speed the rule up. For fast metrics like spend, CTR, or frequency use 15-30 minutes; for slow postback ROAS or CPA metrics use 60+ minutes since the data doesn't move faster. For daily decisions use daily_at_time instead.