Skip to main content
When developing real-time, multimodal AI applications, monitoring two key factors is crucial: performance (latency) and LLM/TTS usage. Performance impacts user experience, while usage can affect operational costs. Pipecat offers built-in metrics for both, which can be enabled with straightforward configuration options.

Enabling performance metrics

Set enable_metrics=True in PipelineParams when creating a worker:
Example config
Once enabled, Pipecat logs the following metrics:
Sample output

Limiting TTFB responses

If you only want the first TTFB measurement for each service, you can optionally pass report_only_initial_ttfb=True in PipelineParams:
Example config
Note: enable_metrics=True is required for this setting to have an effect.

Disabling initial empty metrics

By default, Pipecat sends an initial MetricsFrame with zero values for all services when the pipeline starts. To disable this behavior:
Example config

Enabling LLM/TTS Usage Metrics

Set enable_usage_metrics=True in PipelineParams when creating a worker:
Example config
Pipecat will log the following as applicable:
Sample output
Note: Usage metrics are recorded per interaction and do not represent running totals.

Capturing Metrics Data

When metrics are enabled, Pipecat emits a MetricsFrame for each interaction. The MetricsFrame contains a list of metrics data objects, which can include:
  • TTFBMetricsData — Time To First Byte
  • TTFAMetricsData — Time To First Audio (TTS)
  • ProcessingMetricsData — Processing time
  • LLMUsageMetricsData — LLM token usage
  • TTSUsageMetricsData — TTS character usage
  • TextAggregationMetricsData — Sentence aggregation latency (TTS)
  • TurnMetricsData — Turn completion predictions
You can access the metrics data by either adding a custom FrameProcessor to your pipeline or adding an observer to monitor MetricsFrames.

Example: Using MetricsLogObserver

The simplest way to log metrics is with the built-in MetricsLogObserver. Pass it as an observer when creating your PipelineWorker:
You can filter which metrics types are logged by passing include_metrics:

Example: Using a Custom FrameProcessor

Create a custom FrameProcessor to handle metrics data. Here’s an example Metrics Processor that can be added to your pipeline after the TTS processor.

Metrics Data Reference

All metrics data classes inherit from MetricsData, which includes processor (the name of the processor that generated the metric) and an optional model field.

TTFBMetricsData

Time To First Byte — measures how long until the first byte of a response is received from a service.

TTFAMetricsData

Time To First Audio — measures the time from a TTS request to the first audible audio sample. This includes the time to first byte plus any leading silence padding added by the service. TTFAMetricsData reports the latency breakdown directly, showing how much of the perceived latency is silence padding.

ProcessingMetricsData

Measures the total time taken by a service to process a request.

TextAggregationMetricsData

Measures the time from the first LLM token to the first complete sentence, representing the latency cost of sentence aggregation in the TTS pipeline.

LLMUsageMetricsData

Token usage for an LLM interaction. The value field is an LLMTokenUsage object with:

TTSUsageMetricsData

Character usage for a TTS interaction.

TurnMetricsData

Metrics from turn completion prediction, emitted by turn analyzers like Krisp Viva Turn and Smart Turn. In addition to MetricsLogObserver, Pipecat provides observers that track higher-level conversational metrics.

StartupTimingObserver

Measures the time taken by each processor to start up.
Additionally, it tracks the time taken to connect to the transport and the time taken to connect to the client.

UserBotLatencyObserver

Measures the time between when a user stops speaking and when the bot starts speaking.

TurnTrackingObserver

Tracks conversation turns, emitting events when turns start and end. Handles interruptions and configurable timeouts.