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()throughStartFramepropagation - 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
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.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.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.