Triggers with Metrics - Honeycomb Docs

Beta Set alerts on metrics with custom threshold logic and temporal aggregation functions.

This feature is in beta, and we would love your feedback!To opt in, join our Pollinators Community Slack and ping us in the #discuss-metrics channel. Pro and Enterprise users can also contact Honeycomb Support or email support@honeycomb.io.

Introduction

This guide walks you through working with metrics-based Triggers during the Metrics Beta. You will learn how to create and update metrics-based Triggers, see example configurations, and understand key limitations and differences from event-based Triggers.

Creating a Metrics-Based Trigger

Setting up a metrics-based Trigger works much like setting up an event-based Trigger, with a few key differences tailored to how metrics behave. To create a metrics-based Trigger:

Select Triggers () from the navigation menu.
Select New Trigger.
In the modal that appears, select the Metrics dataset.
If you already had a dataset named Metrics before joining the beta, your metrics dataset may be named OTLP Metrics or Metrics Data.
Define the Trigger query:
- Enter a name and description.
- Select fields from your metrics dataset.
- Optionally, use query-scoped Calculated Fields to apply temporal aggregation functions like RATE() or INCREASE(), which compute change over time. Example: my_rate_dc RATE(http_requests_total).
- Ensure the query returns a single scalar value, not a time series.
  - Most queries start with a temporal aggregation function wrapped in a spatial aggregation like SUM() or AVG(). Example: SUM(my_rate_dc).
  - You can also use spatial aggregations alone on metrics. In this case, Honeycomb applies a default temporal aggregation function based on the metric’s metadata as described in Applying Temporal Aggregation Functions: Default Behavior.
Set threshold conditions and choose where to send notifications.
Select Create Trigger to save.

Your Trigger will evaluate the query at regular intervals (every 15 minutes by default) and send alerts whenever the threshold condition is met.

Modifying a Metrics-Based Trigger

You can modify a metrics-based Trigger the same way you edit an event-based Trigger. To modify a metrics-based Trigger:

Select Triggers () from the navigation menu.
Find the Trigger you want to update, and select its name.
In the editor, adjust the query, threshold, or notification settings as needed.
Select Save Trigger to apply your changes.

You cannot change a Trigger’s dataset after it has been created. To use a different dataset, create a new Trigger.

Examples

Use these examples as a starting point for building your own metrics-based Triggers. Each highlights a common use case and shows how to structure the Trigger query.

Define your calculated field before using it in a Trigger. You can do this while building the Trigger; appropriate clauses in the query editor include a Define calculated field option.

Error Rate Spike

Goal: Detect a spike in errors
Calculated Field: my_error_rate RATE($k8s.pod.network.errors)
Trigger Query: AVG(my_error_rate)
Threshold: > 0.05

This configuration alerts when the average error rate across the Environment exceeds 5%.

Saturation Check

Goal: Detect a spike in CPU usage
Calculated Field: last_cpu_util LAST($k8s.pod.cpu.utilization)
Trigger Query: AVG(last_cpu_util)
Threshold: > 0.9

This configuration tracks the most recent CPU utilization across containers and alerts when it rises above 90%. It uses LAST() to get the most recent sample for each container.

Throughput Threshold

Goal: Detect sustained high request volume
Calculated Field:incr_requests INCREASE($http.server.requests, 300)
Trigger Query: SUM(incr_requests)
Threshold: > 1000

This configuration alerts when total requests in the last 5 minutes exceed 1000.

Limitations

Keep the following constraints in mind when working with Metrics-based Triggers:

Define temporal aggregation functions like RATE() or INCREASE() in query-scoped calculated fields, then reference them in your Trigger’s query. You cannot use temporal aggregation functions directly inside aggregations like SUM() or AVG().
Metrics-based Triggers are not yet optimized for large-scale datasets. Standard Honeycomb trigger limits still apply, but we recommend using them conservatively during the beta to ensure stable performance.
Pre-built templates are not available for metrics-based Triggers.

Compare Metrics-Based and Event-Based Triggers

Metrics-based and event-based Triggers share a similar setup process, but they behave differently in how they evaluate data and support configuration.

Feature	Metrics-Based Triggers	Event-Based Triggers
Temporal Aggregation	Via Calculated Fields only	Not applicable
Query Preview	One bucket only; no 16x view	16x historical preview
Templates	Not supported	Supported
Granularity Selector in UI	Available	Not Applicable

​Introduction

​Creating a Metrics-Based Trigger

​Modifying a Metrics-Based Trigger

​Examples

​Limitations

​Compare Metrics-Based and Event-Based Triggers

Introduction

Creating a Metrics-Based Trigger

Modifying a Metrics-Based Trigger

Examples

Limitations

Compare Metrics-Based and Event-Based Triggers