Short answer: there isn’t a supported switch to stop emitting just task events in Prefect 3.x. Task-run events are produced whenever task states change, and selective “don’t emit task.*” at the client/worker level isn’t available. Depending on your goal, here are practical options: - Keep automations clean (no task events) - Configure automations to only react to flow-run events. Using wildcards, only include

prefect.flow-run.*

in your triggers’ expectations so task events never drive actions. - Example (Python API):

from prefect.server.events.schemas.automations import EventTrigger, Automation, Posture

    trigger = EventTrigger(
        posture=Posture.Reactive,
        expect={"prefect.flow-run.*"},   # only flow-run events
        threshold=1,
        within=0,
    )
    automation = Automation(name="Flow-only automation", trigger=trigger, actions=[...])

- Docs: Event triggers concept - Filter events when consuming/querying - If you’re building tools or subscriptions around events, use filters to exclude task-run events:

from prefect.server.events.filters import EventFilter, EventNameFilter

    event_filter = EventFilter(
        event=EventNameFilter(exclude_prefix=["prefect.task-run"])
    )

- API reference: Event filter classes - Reduce storage/noise at the server level (self-hosted Prefect Server only) - Shorten event retention so task events don’t accumulate: -

PREFECT_SERVER_EVENTS_RETENTION_PERIOD=P1D

(default is

P7D

) - As a stronger measure, you can disable event persistence/logging entirely (this affects all events, not just tasks): -

PREFECT_SERVER_SERVICES_EVENT_PERSISTER_ENABLED=false

-

PREFECT_SERVER_SERVICES_EVENT_LOGGER_ENABLED=false

- Settings reference: Settings reference Notes and trade-offs: - There is no built-in way to disable only task events at emission time; filtering is done when reacting to or querying events. - Disabling the event persister/logger turns off event-derived features (automations, notifications, event timeline) across the board. A couple of questions so I can point you to the best setup: - Are you on Prefect Cloud or self-hosting Prefect Server? - Is your goal to hide task events from automations/UI, reduce database/storage usage, or reduce network traffic from workers?

Got it — since you’re self-hosting and want to cut both worker network traffic and DB load: What’s possible today - There is no supported client-side switch to emit “only flow events” or to turn off task events. Workers will emit events for state changes if the event stream is available. - Disabling event persistence/logging reduces DB load but does not stop workers from attempting to send events. Practical ways to hit your goals 1) Minimize/stop event writes to your database - Disable the event persister (drops all events instead of writing them): -

PREFECT_SERVER_SERVICES_EVENT_PERSISTER_ENABLED=false

- Optional: disable server-side event logging (console logs of events): -

PREFECT_SERVER_SERVICES_EVENT_LOGGER_ENABLED=false

- If you still want some events but less storage, shorten retention: -

PREFECT_SERVER_EVENTS_RETENTION_PERIOD=P1D

(default is

P7D

) - Settings reference: Settings reference 2) Reduce worker network traffic caused by events - There isn’t an official worker/client flag to disable event emission only. Two patterns that teams use in self-hosted environments: - Block the events “out” WebSocket at your API gateway/ingress (the path workers use to send events, typically

/api/events/out

). With that endpoint blocked (404/403), workers will fail to establish the events channel and drop events instead of streaming them. Flow/task orchestration and logs continue to work. You’ll see minimal retry traffic, but not a steady event stream. - Disable the server’s event stream. Set: -

PREFECT_SERVER_EVENTS_STREAM_OUT_ENABLED=false

This turns off the event stream; clients treat events as unavailable and stop sending. Note: this disables event-driven features (automations, the event timeline, incident features). Trade-offs to be aware of - Turning off persistence or the stream disables event-derived features: automations, notifications triggered by events, and the event timeline in the UI. - Logs are separate from events; they’ll keep flowing unless you change logging settings. If you can share how your API is exposed (e.g., NGINX/Ingress/Gateway), I can suggest a concrete rule to block the

/api/events/out

path safely. Also, confirm you’re okay losing automations/event timelines; if yes, the “disable stream + disable persister” combo will give you the biggest drop in worker traffic and DB load.