StartupTimingObserver measures how long each processor’s start() method takes during pipeline startup, 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
start()duration by trackingStartFramepropagation - Reports total pipeline startup time and per-processor breakdown
- Tracks transport connection milestones (bot connected, client connected)
- Emits
on_startup_timing_reportwith processor timing data - Emits
on_transport_timing_reportwith 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 aprocessor_types tuple:
Configuration
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.StartupTimingReport):
Processor timing fields (
ProcessorStartupTiming):
on_transport_timing_report
Called once when the first client connects, with transport connection timing relative to theStartFrame.
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.