It’s not something I’d call “common” in the sense of “expected behavior,” but false-looking automation triggers can happen because automations are driven by events, not just what the UI summary makes obvious. For your specific automation — “any flow run stays in

running

or

retrying

for 7 days” — the trigger logic is basically: - see a

Running

or

Retrying

event - wait 7 days - if no matching terminal event is seen in that window, fire the automation So if the UI later shows that run only lasted a few seconds, that usually suggests one of these: 1. The automation saw an event sequence that was incomplete or delayed - e.g. it saw

Running

, but the terminal event it expected wasn’t available in time for evaluation 2. The trigger is matching a run/event you’re not interpreting the same way from the UI - sometimes the “causing” run in the dashboard is confusing unless you inspect the exact event trail 3. There may be an event-ordering / timestamp discrepancy - Prefect automations rely on event timing and processing, not just the final rendered duration in the UI A few important details: -

Retrying

is a state name under a running-type state, so transitions through retry logic can create separate events. - Proactive automations like this one fire based on the absence of expected events over time. - Prefect’s event system has ordering/buffering logic, so under some conditions an automation can appear to fire “for no reason” if the relevant terminal event wasn’t considered in the right window. Relevant docs: - Event triggers - Flow run events - Detect zombie flows — this is related because it uses the same proactive “missing event within time window” pattern What I’d recommend checking next: 1. Open one of the triggered automation executions and inspect: - the triggering event type - the

occurred

timestamp - the resource id / flow run id 2. Compare that to the flow run’s state history - was there definitely a

Completed

,

Failed

,

Crashed

, or

Cancelled

state after the `Running`/`Retrying` event? 3. Check whether the run was resubmitted / retried / recreated - sometimes multiple state transitions for the same run make this less obvious 4. If possible, look at the raw events for that flow run rather than only the duration shown in the run UI If you want, I can help you narrow this down. If you paste: - the automation trigger configuration - one example flow run id - what terminal state that run ended in I can help you reason through whether this looks like expected event semantics, misconfiguration, or a possible bug. If it does look like a bug, the best public contact paths are: - GitHub issues: prefect issues - Community discussion: prefect discussions

✅ thought for 16.9 seconds

Yes — this example is actually quite informative. What this event does show is: - the automation fired at

2026-06-26T02:10:31.106Z

- because it saw a

prefect.flow-run.Running

event at

2026-06-19T02:10:31.042899Z

- for flow run

prefect.flow-run.06a34a4e-73a2-7e31-8000-2207ced6cd2d

That is almost exactly 7 days later, so the automation engine behaved consistently with a proactive “still running after 7 days” rule. The key thing missing from this payload is: there is no evidence here that the automation ever saw a terminal event for that same flow run. That’s the whole story. If the run truly finished in ~7 seconds, then for this automation not to fire, Prefect would have needed to observe a later event for the same

prefect.resource.id

such as one of: -

prefect.flow-run.Completed

-

prefect.flow-run.Failed

-

prefect.flow-run.Crashed

-

prefect.flow-run.Cancelled

before

2026-06-26T02:10:31.042899Z

. From the body you pasted, we can infer a few concrete things: 1. The trigger was keyed by the flow run id

"triggering_labels": {
  "prefect.resource.id": "prefect.flow-run.06a34a4e-73a2-7e31-8000-2207ced6cd2d"
}

So this wasn’t some unrelated run accidentally attached in the UI. It was definitely watching that exact run. 2. The triggering event was the transition into

Running

"event": "prefect.flow-run.Running"
"prefect.state-timestamp": "2026-06-19T02:10:31.042899+00:00"

So the automation’s 7-day timer started there. 3. The event was received normally

"received": "2026-06-19T02:10:31.146845Z"

Only ~100ms after

occurred

, so this does not look like a delayed-arrival problem for the

Running

event. 4. The run sat in

Pending

for ~47 seconds before

Running

- `Pending`:

02:09:43.693502

- `Running`:

02:10:31.042899

That’s interesting operationally, but not relevant to the false trigger by itself. So the concrete conclusion is: This automation fired because, from the event system’s perspective, that flow run entered

Running

and no qualifying terminal flow-run event cancelled the 7-day watch. That leaves a few plausible explanations: Most likely explanation: the run UI and the event stream disagreed for that run - The run may show as having completed in a few seconds - but the matching `Completed`/`Failed`/etc event may never have been emitted, ingested, or associated properly for automations Other plausible explanation: your automation’s expected “ending states” don’t include the actual terminal state/event - If the automation was configured through the UI, this is less likely, but still possible depending on the exact rule - For example, if the run ended in a state/event that your trigger does not treat as resolving the watch, it would still fire Less likely from this payload: clock skew or late processing of the

Running

event - the

Running

event timing looks normal What I’d check next, very specifically: For this exact flow run id

06a34a4e-73a2-7e31-8000-2207ced6cd2d

, find whether there exists a terminal event with the same

prefect.resource.id

. You want to see one of these after `2026-06-19T021031.042899Z`: -

prefect.flow-run.Completed

-

prefect.flow-run.Failed

-

prefect.flow-run.Crashed

-

prefect.flow-run.Cancelled

If you can inspect the run’s event history and you do not see one of those, then the automation is behaving correctly and the issue is really: “why did this flow run appear to finish in the UI without a terminal flow-run event?” If you do see one of those events for the same run id before the 7-day deadline, then this starts to look like a real automation bug. One more subtle thing I notice: The automation event references the triggering event as:

"related": [
  {
    "prefect.resource.id": "prefect-cloud.event.06a34a51-70af-798d-8000-bd77afb1e738",
    "prefect.resource.role": "triggering-event"
  }
]

That means the automation is tied to one specific source event object, not just a generic run record. So if a later terminal state exists only in the run database/UI layer but not in the event stream, the automation would still fire. So, concretely: I do not think this is “for no reason.” I think the reason is: Prefect Cloud saw

Running

for that run, and apparently did not see a terminal event that would close the proactive trigger window. If you want, send me either: - the event/history list for that same run id, or - a screenshot/copy of the run’s state timeline and I can help determine whether this is: - missing terminal event ingestion, - a mismatch between UI state history and automation events, - or a mis-specified trigger.