Great question! To clarify first: do you want to run a flow only on certain weekdays, or do you want an Automation (e.g., a Slack notification) to fire only on certain weekdays? Here are the common patterns in Prefect 3.x: - To run a flow on specific weekdays: use a deployment schedule (Cron or RRule). This is the simplest and most reliable. - To limit Automations (notifications/actions) to weekdays: there isn’t a built-in “weekday-only” filter on Automations today. Typical workarounds are: - Ensure the upstream event only occurs on weekdays (e.g., your flow is scheduled Mon–Fri). - Route the Automation to a webhook you control and ignore off-hours in that endpoint. - Operational workaround: rely on Slack/Teams DND/schedules. Examples (Prefect 3.x): - Cron schedule for weekdays at 9am ET

from prefect import flow
from prefect.schedules import Cron

@flow
def my_flow():
    print("Hello from a weekday!")

schedule = Cron("0 9 * * 1-5", timezone="America/New_York")

my_flow.from_source(
    source="<https://github.com/owner/repo>",
    entrypoint="flows/my_flow.py:my_flow",
).deploy(
    name="weekday-9am",
    work_pool_name="my-pool",
    schedule=schedule,
)

- RRule schedule for weekdays at 9am ET

from prefect import flow
from prefect.schedules import RRule

@flow
def my_flow():
    print("Hello from a weekday!")

schedule = RRule(
    rrule="FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=9;BYMINUTE=0;BYSECOND=0",
    timezone="America/New_York",
)

my_flow.from_source(
    source="<https://github.com/owner/repo>",
    entrypoint="flows/my_flow.py:my_flow",
).deploy(
    name="weekday-9am",
    work_pool_name="my-pool",
    schedule=schedule,
)

Doing this at the deployment level ensures the flow (and thus most downstream events an Automation might listen to) only occur on weekdays. Cloud UI tips: - To schedule a deployment for weekdays, open the deployment in the UI → Edit schedule → choose Cron or RRule. - Cron example: minute=0, hour=9, day-of-week=1-5. - RRule example: BYDAY=MO,TU,WE,TH,FR; BYHOUR=9; BYMINUTE=0; BYSECOND=0. - Automations are event-driven and don’t currently have a native “weekday-only” condition. If you must filter Automations by time, the most robust approach is to ensure the triggering event only happens during your desired window (via the deployment schedule) or to send the Automation to a webhook that enforces business hours. Docs: - Schedules (concepts) - Schedules (API) If you share your specific goal (e.g., “send Slack alerts only Mon–Fri” vs “only run this flow Mon–Fri”), I can suggest the cleanest setup.

Great question. In Automations, “Evaluate trigger only after observing an event matching” is a gate. When you enable it and define a matching event, the trigger stays dormant and will not evaluate at all until a new event that matches that filter is observed. Once such an event arrives, the trigger “wakes up” and evaluates normally; many time-based windows are then measured relative to that kickoff event. Why/when to use it - Prevent false positives on creation: For “no events for X duration” triggers, this avoids firing immediately just because nothing has happened yet. - Anchor checks to a session: “Alert if no Completed within 30m after a run starts” — the 30 minutes starts when a “run started/running” event is seen. - Ignore historical events: It only considers events observed after the automation is enabled (or after the last reset). Typical patterns - Absence alert anchored to a start event: - Gate on “Flow run entered Running” - Trigger when “no Flow run Completed” for 30 minutes - Result: Timer starts at the first new Running event; if no Completed arrives in 30m, the automation fires. - Health checks that should begin only after a system starts: - Gate on “Worker Started” - Trigger on “no Worker Heartbeat” for 10 minutes Behavior details and edge cases - Historical events: They do not start evaluation; the trigger waits for a new matching event after you enable or resume the automation. - Reset on new kickoff: Each new matching kickoff event resets/anchors evaluation to the latest one. - Duplicates: Duplicate events are ignored; the gate uses newly observed, distinct events. - Pausing/resuming: When paused and then resumed, it will again wait for the next matching kickoff event before evaluating. Notes on posture/types - For “reactive” triggers (fire when an event occurs), the gate usually makes little difference since the event itself is the trigger. - For “proactive/absence” triggers (fire when something does not occur for a duration), the gate is key to avoid immediate alerts and to scope the duration relative to a meaningful start. UI tip - In the Automation builder, expand “Evaluation options,” enable “Evaluate trigger only after observing an event matching,” and build the kickoff event filter (e.g., Event name = flow-run entered Running, with optional resource filters/tags). Docs - Event triggers (concepts) - Automations and observability (blog) If you share your specific scenario (which event you care about, and what “should/shouldn’t happen” within what window), I can help you configure the exact filters and options.