Triggers with Metrics 2.0

Beta

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

Important

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 2.0 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.

Tip

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.

Note

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.

Tip

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

Metrics-based Triggers are still in development and come with a few key constraints:

Temporal aggregation functions must use Calculated Fields You cannot use temporal aggregation functions like RATE() or INCREASE() directly inside aggregations like SUM() or AVG(). Instead, define them in query-scoped Calculated Fields and reference those in your Trigger’s query.
Performance may vary at scale Metrics-based Triggers are not yet optimized for large-scale datasets. Standard Honeycomb trigger limits still apply, but we recommend conservative use during the beta to ensure stable performance.
Templates not yet available Unlike event-based Triggers, metrics-based Triggers do not currently offer pre-built templates.

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