<@ULVA73B9P> Are you awake :slightly_smiling_face:...
# ask-community
z
@Marvin Are you awake 🙂?
m
✅ thought for 2.5 seconds
Always! How can I help you with Prefect today? 😊
z
@Marvin I have proactive automation with configuration { "type": "event", "match": { "prefect.resource.id": [ "sales_margins_workflow" ] }, "match_related": { "prefect.resource.id": [ "prefect.flow.107a9c09-6dda-4aec-9f1b-d487721af651" ] }, "after": [ "addresses.processed" ], "expect": [ "sales_margins_all_countries.processed" ], "for_each": [], "posture": "Proactive", "threshold": 1, "within": 7200 } If I create this automation after event "addresses.processed" was already emitted and it is emitted once a day it fires this automation every 4 hours. why?
m
✅ thought for 430.9 seconds
Short answer: because the automation is “proactive” and you created it after the last “addresses.processed” event, it immediately opens a “missing expectation” incident and keeps re-notifying while the expectation remains unmet. In Cloud today, unresolved proactive incidents are re-notified on a fixed cadence of about 4 hours, so you’ll see it fire repeatedly until: - a new “addresses.processed” event occurs (starting a fresh window), - the expected “sales_margins_all_countries.processed” event appears, or - you pause/disable the automation. Why this happens with your config - posture: Proactive + after + expect + within=7200s means: “after we see addresses.processed, we expect sales_margins_all_countries.processed within 2 hours; if not, trigger.” - When you create the automation after the “after” event already happened, the system uses the most recent matching “after” event as the start of the window. Since you’re already beyond the 2-hour “within” window, it fires right away. - While the expectation remains unmet and no newer “after” event arrives, the platform keeps the incident open and re-notifies on its cadence (about every 4 hours). Ways to avoid repeated notifications in this scenario - Create/enable the automation before the next daily “addresses.processed” event so the window starts cleanly. - Temporarily set posture to Reactive (or pause/disable the automation) until the next “addresses.processed” event occurs. - If you only want a single notification per “after” occurrence, keep the automation disabled until the next “addresses.processed”, then enable it right after that event fires. - Optionally, narrow who/what it applies to via for_each to reduce duplicate noise across resources; it won’t stop re-notify for a single overdue expectation, but it helps avoid fan-out if multiple resources are involved. References - Event triggers and automations (Prefect 3) If you share which action(s) your automation runs and whether you want only one notification per “after” or periodic reminders until recovery, I can suggest an exact config tweak or workflow change.