Skip to main content
The StartupTimingObserver measures what each processor costs to get ready — its setup() and its start() together — and tracks transport connection timing. This is useful for diagnosing startup slowness and identifying initialization bottlenecks such as WebSocket connections, API authentication, or model loading.

Features

  • Measures per-processor readiness cost, from setup() through StartFrame propagation
  • Reports total pipeline startup time and per-processor breakdown
  • Tracks transport connection milestones (bot connected, client connected)
  • Emits on_startup_timing_report with processor timing data
  • Emits on_transport_timing_report with transport connection timing
  • Supports filtering to measure only specific processor types
  • Excludes internal pipeline processors by default

Usage

Basic Startup Monitoring

Add startup monitoring to your pipeline and handle the events:

Filtering Processor Types

To measure only specific processor types, pass a processor_types tuple:

Configuration

Tuple[Type[FrameProcessor], ...] | None
default:"None"
Optional tuple of processor types to measure. If None, all non-internal processors are measured. Internal pipeline processors (PipelineSource, Pipeline) are always excluded.

Event Handlers

on_startup_timing_report

Called once after the pipeline has fully started, with timing data for all measured processors.
Report fields (StartupTimingReport): Processor timing fields (ProcessorStartupTiming):

on_transport_timing_report

Called once when the first client connects, with transport connection timing measured from the moment the pipeline began setting up.
Report fields (TransportTimingReport):
bot_connected_secs is only set for SFU transports (Daily, LiveKit, HeyGen, Tavus) that emit a BotConnectedFrame when the bot joins the room. Non-SFU transports (WebSocket, SmallWebRTC) will have this field set to None.