Short answer - With single‑node Redis, if Redis is down when the API tries to publish events, the API request will fail; Prefect does not buffer events for later delivery at the API layer. Previously published events remain safe in Redis and will be consumed once Redis is back. - There’s no built‑in distributed trace id across API → background services. You can use the event’s

id

, the

follows

field for causal chains, and include your own

trace_id

in the event payload for correlation. Details and recommendations What happens during a Redis outage - API publishing - In Prefect 3.x (including 3.6.21), the API publishes directly to the configured messaging broker (Redis Streams when using the Redis integration). - If Redis is unavailable at publish time, the publish call raises an error and the HTTP request fails (no built‑in retry/backoff and no durable buffer in the API). This means events generated during an outage are not preserved by the API server; the caller must retry. - Background services (consumers) - Consumers use Redis Streams consumer groups with at‑least‑once semantics and pending entry reclamation. If Redis is down for a few minutes, services will reconnect with backoff and continue from pending/new messages when Redis returns. - Durability of already‑published events depends on Redis persistence (enable AOF or appropriate RDB settings). How to minimize risk of loss - Use highly available Redis - Prefer a managed Redis with automatic failover or deploy Redis with Sentinel/cluster behind a stable endpoint to avoid the single point of failure. - Ensure persistence - Enable AOF (append‑only file) for near‑synchronous durability of published events. - Add retries at the producer - Since the API returns a non‑2xx when Redis is down, make the event‑emitting client retry with exponential backoff. - If you need hard guarantees, place a durable queue or buffer in front of the Prefect Events API (e.g., a proxy that queues/retries). - Configure causal ordering with Redis - Set

PREFECT_SERVER_EVENTS_CAUSAL_ORDERING=prefect_redis.ordering

so causal chains (

follows

) are tracked durably in Redis. Tracing/correlating events - Use these fields: - `id`: unique per event (you can set it; otherwise one is generated). Good for deduplication and lookup. - `follows`: set to the previous event’s

id

to build a causal chain. - Custom payload: include your own

trace_id

and any correlation keys you want to follow in logs/queries. - Querying/observability: - Events are persisted by the event‑persister to your database. You can query by

id

, resource, and time via the REST API or UI. - Include

trace_id

in your own logs (API clients and any user code) so you can correlate with event rows later. Minimal example of traceable events

import uuid
from prefect.events import Event, emit_event

trace_id = str(uuid.uuid4())

# First event
e1 = Event(
  event="my.op.started",
  resource={"prefect.resource.id": "my-op/123"},
  id=uuid.uuid4(),
  payload={"trace_id": trace_id},
)
await emit_event(e1)

# Follow-up event causally linked
e2 = Event(
  event="my.op.step.completed",
  resource={"prefect.resource.id": "my-op/123"},
  id=uuid.uuid4(),
  follows=e1.id,
  payload={"trace_id": trace_id, "step": "fetch"},
)
await emit_event(e2)

Key docs - Events overview and fields (including

follows

): Events concept - Self‑hosted with Redis (architecture and config): Self‑hosted guide - Redis integration (messaging): Prefect Redis messaging API - Settings reference (messaging broker, Redis, causal ordering): Settings reference - Events REST API (read/write): Events REST API

If you share a bit more about your Redis deployment (managed vs self‑hosted, Sentinel/cluster availability, persistence settings) and how your clients emit events (direct HTTP vs Python SDK vs WebSocket), I can suggest a concrete HA and retry pattern tailored to your setup.