Skip to main content
The 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 tracking 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

processor_types
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 relative to the StartFrame.
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.