Short answer: No.

PREFECT_EVENTS_WEBSOCKET_TIMEOUT

is not a valid Prefect 3.x environment variable. If you’re trying to tune events/websocket behavior, these are the relevant settings: - Client-side: -

PREFECT_EVENTS_WORKER_MAX_QUEUE_SIZE

— max queued events before dropping new ones - Source: EventsSettings source - Server-side (websocket-related): -

PREFECT_SERVER_EVENTS_STREAM_OUT_ENABLED

-

PREFECT_SERVER_EVENTS_MAXIMUM_WEBSOCKET_BACKFILL

-

PREFECT_SERVER_EVENTS_WEBSOCKET_BACKFILL_PAGE_SIZE

- Source: ServerEventsSettings source If you can share what behavior you’re trying to change (e.g., avoid websocket idle timeouts, adjust reconnection, etc.), I can point you to the right setting or workaround.

Thanks for the details — that error maps to a websocket “opening handshake” timing out during startup, which can cause the flow-run container to exit. A few important notes up front: - The events websocket handshake uses the websockets library default open_timeout (~10s) — there’s no

PREFECT_EVENTS_WEBSOCKET_TIMEOUT

setting to change this. - In recent Prefect 3.6 releases we added retries on the initial websocket connect so transient startup/network blips don’t kill the run. Recommended steps to reduce/resolve this: 1) Upgrade Prefect to the latest 3.6.x - We’ve shipped improvements so handshake failures don’t hard-fail runs and 4xx rejections degrade gracefully. - See: Add retry logic to initial websocket connection and Degrade gracefully when events WebSocket is rejected. Latest notes: Release notes 2) Verify network/DNS reachability from your flow-run container to the events websocket endpoint - Endpoint used by flow runs:

wss://<your-prefect-api>/api/events/out

- Source code ref: events clients (subscriber connects to

/events/out

) - From the container, test DNS and TLS reachability (e.g.,

nslookup <host>

,

curl -I https://<host>/api/health

) 3) If you’re self-hosting behind custom TLS or an internal CA - Provide the CA chain with

PREFECT_API_SSL_CERT_FILE

or, for testing only, set

PREFECT_API_TLS_INSECURE_SKIP_VERIFY=true

- API settings reference: APISettings 4) If you’re on Kubernetes and this only happens during pod startup - It’s often a startup race (DNS/egress not yet ready). Consider: - Letting the job retry (K8s Job backoff) so a transient handshake failure doesn’t permanently fail the run - A short init-container wait for network readiness if your cluster is slow to warm - Related discussion: Issue: websocket handshake timeout killed flow 5) Turn on more logging to capture the exact failure - Set

PREFECT_LOGGING_LEVEL=DEBUG

and share the stack trace that includes “timed out during opening handshake” A couple of quick questions to help me tailor the fix: - What Prefect version are you on? - Prefect Cloud or self-hosted? If self-hosted, what’s in front of the API (Ingress/LB, TLS termination)? - Are your flow runs on Kubernetes (which distro), Docker, or something else? - Any proxies/egress restrictions in the path? - Can you share a short log snippet around the failure (the lines with “timed out during opening handshake”)? If you prefer a quick mitigation while we fine-tune networking, upgrading to the latest 3.6.x is the best first step — it adds initial connection retries so transient timeouts won’t immediately crash the container.