Honeycomb is migrating all Free and Pro customers from our original metrics-as-events offering to our new native time series metrics.
This FAQ covers what is changing, what you need to do, and how to update your queries, Boards, and Triggers.
The basics
Before you get started, here is what you need to know about what is changing and why.
What is changing?
Honeycomb’s original metrics implementation stored your metric data as events, the same format as traces and logs.
Our new time series metrics platform natively stores time series data points, which is the format metrics are designed to use.
This means better query accuracy, proper support for counters and histograms, and metrics that no longer count against your event allotment.
Why are we doing this?
Time series metrics are more accurate and more powerful for their intended use cases.
While we continue to recommend instrumenting as much of your telemetry in traces and wide events as possible, time series metrics have great supplemental value.
Time series data points let Honeycomb properly handle counter resets, rate calculations, histogram aggregations, and temporal aggregation functions like RATE and INCREASE.
These functions were potentially less accurate when metrics were stored as events.
Moving to time series metrics also frees up your event budget for traces and structured logs, which is where events belong.
When is this happening?
On June 10, 2026, Honeycomb will enable time series metrics for Free and Pro customers.
Here is what will happen:
- If you are on a Free or Pro plan and not currently sending metrics-as-events: Honeycomb moves you directly to time series metrics. No action required.
- If you are on a Free or Pro plan and currently sending metrics-as-events: Your account enters dual ingest mode, where Honeycomb simultaneously writes your metrics as both metrics-as-events and time series metrics.
After 60 days, you will have the same retention window of data written in both formats, but you can start working with your time series metrics today.
You have approximately 6 months from June 10 to complete your migration. At the close of that window, metrics-as-events will be deprecated for Free and Pro plans.
- If you are on an Enterprise plan and currently sending metrics-as-events: Your existing setup is not affected by this migration.
Honeycomb does not plan to deprecate metrics-as-events for Enterprise customers on existing contracts.
Free and Pro accounts created after June 10, 2026 are already on time series metrics by default.
What do I need to do?
The short answer is: you do not need to change how you send metrics.
The work is in updating how you query them.
Do I need to change how I send metrics?
No.
If you are already sending metrics via OTLP, your instrumentation stays exactly the same.
Honeycomb handles the routing on the backend.
You do not need to change your collectors, SDKs, or pipelines.
What do I actually need to update?
The main work is in how you query your metric data.
Because metrics-as-events and time series metrics use fundamentally different storage formats, queries written for metrics-as-events require rebuilding to work on time series metrics data.
Unfortunately, Honeycomb doesn’t provide an automated migration tool.
Your Boards, queries, and Triggers that use metric data will need to be rebuilt and pointed at the time series metrics dataset.
- Board queries: Recreate queries written for metrics-as-events using time series metrics aggregation functions.
- Triggers: Rebuild any Triggers querying metrics-as-events against time series metrics.
- Service Level Objectives (SLOs): Time series metrics are not supported in SLOs. For alternatives, refer to the SLOs section.
During dual ingest, your existing metrics-as-events Boards and Triggers will continue to work.
Use that window to rebuild them against time series metrics at your own pace.
How querying changes
Metrics-as-events and time series metrics use different storage models, which means the query functions that worked before need to be updated.
This section explains what has changed and how to translate your existing queries.
What is different about querying time series metrics?
With metrics-as-events, Honeycomb stored your metrics as events, and aggregations like AVG, SUM, and COUNT worked the same way they do on trace data.
With time series metrics, Honeycomb stores your data as time series data points with semantic types (counters, gauges, and histograms), and applies appropriate temporal aggregations based on that type.
The key new aggregation functions are:
| Function | Use for | What it does |
|---|
RATE(metric) | Counters | Calculates the per-second rate of increase |
INCREASE(metric) | Counters | Calculates the total increase over the query window |
LAST(metric) | Gauges | Returns the most recent value in each time bucket |
SUMMARIZE(metric) then AVG/MAX/etc. | Gauges | Lets you apply spatial aggregations to gauge data |
COUNT_DATAPOINTS(metric) | Any | Counts the number of data points received (replaces COUNT) |
HISTOGRAM_COUNT(metric) | Histograms | Counts the number of observations captured in a histogram |
Counter metrics
With metrics-as-events, Honeycomb stored a counter like http.server.request.count as an event with a numeric value, and querying AVG(http.server.request.count) might have returned something useful.
With time series metrics, Honeycomb knows this is a cumulative counter.
Asking for the average of a running total isn’t meaningful; what you actually want is the rate of increase or the total increase over a window.
| Metrics-as-events query | Time series metrics equivalent |
|---|
COUNT(http.server.request.count) | RATE(http.server.request.count) |
SUM(http.server.request.count) | INCREASE(http.server.request.count) |
AVG(http.server.request.count) | RATE(http.server.request.count) |
Gauge metrics
Gauges represent a current state: CPU utilization, memory usage, queue depth.
With metrics-as-events, AVG(system.cpu.utilization) worked reasonably well.
With time series metrics, query a gauge using LAST to get the most recent value, or use SUMMARIZE to flatten it first and then apply a spatial aggregation.
| Metrics-as-events query | Time series metrics equivalent |
|---|
AVG(system.cpu.utilization) | LAST(system.cpu.utilization) |
MAX(system.cpu.utilization) | SUMMARIZE(system.cpu.utilization) → MAX |
INCREASE is not supported on gauge metrics.
If you are tracking something that only makes sense as an increasing value (like restart counts), instrument it as a counter instead.
Histogram metrics
Histograms are the simplest to migrate.
Most existing histogram queries, like P99, HEATMAP, and so on, work the same way with time series metrics.
The main change is that COUNT on a histogram no longer means what it did with metrics-as-events.
| Metrics-as-events query | Time series metrics equivalent |
|---|
COUNT(http.server.request.duration) | HISTOGRAM_COUNT(http.server.request.duration) |
P99(http.server.request.duration) | P99(http.server.request.duration) ✓ |
HEATMAP(http.server.request.duration) | HEATMAP(http.server.request.duration) ✓ |
What happened to COUNT?
COUNT has been removed from the metrics query builder to avoid confusion.
In an event model, counting events makes sense; in a time series model, it is ambiguous and misleading.
Use COUNT_DATAPOINTS(metric_name) to count how many data points arrived for a given metric, or use HISTOGRAM_COUNT for histogram observation counts.
How do I find my time series metrics dataset?
In the Honeycomb UI, your time series metrics dataset has a graph icon () next to its name in the dataset dropdown.
Look for the dataset named metrics (or similar) with that icon.
Point your updated queries, Boards, and Triggers to this dataset.
Can Canvas help me migrate my queries?
Yes!
Canvas (Honeycomb’s AI assistant) is aware of time series metrics query syntax and can help you translate your existing metrics-as-events queries.
Try describing what you were measuring with metrics-as-events and ask Canvas to write the equivalent time series metrics query.
Boards and Triggers
During dual ingest, your existing Boards and Triggers keep working.
Use this section to plan your rebuilds before the migration window closes.
Not during dual ingest.
While your account is in dual ingest mode, your metrics-as-events Boards will continue to function because the metrics-as-events dataset is still receiving data.
Once dual ingest ends and metrics-as-events is turned off, queries pointing to the old dataset will stop returning results.
We strongly recommend rebuilding your most critical Boards and alerts against time series metrics during the migration window, then validating the results while both datasets are running in parallel.
How do I rebuild a Trigger for time series metrics?
Create a new Trigger and point it at your time series metrics dataset.
Use the appropriate time series metrics aggregation function for your metric type (refer to the How Querying Changes section for the full function reference).
The threshold values you used in your metrics-as-events Triggers may need adjustment.
For example, a RATE value will be in units per second, whereas your old SUM value was a raw count.
Step-by-step: Migrating a Trigger
Follow these steps to recreate a metrics-as-events Trigger on your time series metrics dataset:
- Open your existing metrics-as-events Trigger and note the metric name, group-by fields, filter conditions, and threshold.
- Create a new Trigger, selecting your time series metrics dataset.
- Choose the appropriate aggregation (
RATE, INCREASE, LAST, and so on) for your metric type.
- Re-apply your group-by and filter conditions.
- Run a query over a recent time window to understand the expected output range.
- Set your threshold based on what you observe, accounting for the unit change (for example, rate per second vs. raw count).
- Enable the new Trigger and run both in parallel for a week before disabling the old one.
SLOs
Time series metrics are not currently supported in SLOs.
Here is what that means for your existing setup and what to use instead.
Can I use SLOs with time series metrics?
Not currently.
If you have SLOs backed by metrics-as-events data today, we recommend replacing them with an equivalent Trigger or constructing a new SLO based on an event in your telemetry that reflects the customer experience you want to measure.
What can I use instead of SLOs for metrics-based alerting?
Triggers are the recommended alternative.
They support time series metrics queries and can alert you when a metric crosses a threshold, changes rate, or drops below a baseline.
While Triggers don’t give you an error budget visualization the way SLOs do, they cover the core alerting use case.
Other limitations
Time series metrics have a few constraints worth knowing about before you migrate, so you can plan accordingly.
BubbleUp
BubbleUp is not currently supported on time series metrics data.
The BubbleUp option is unavailable when working with heatmaps in the metrics dataset.
Data retention
Honeycomb retains time series metrics data for 13 months by default.
If your environment has a longer retention period configured, Honeycomb honors that longer period for your metrics dataset.
Column limit
Time series metrics supports up to 100,000 metric columns per environment, compared to 10,000 with metrics-as-events.
If you previously hit column limits with metrics-as-events, that limit should no longer be a concern.
All time series metrics operators are supported in the Terraform provider.
Mixing temporal and non-temporal aggregates in API queries will cause those queries to fail; use temporal aggregates consistently within a single query.
High-cardinality metrics
Time series metrics work best with bounded attribute values.
High-cardinality attribute values (for example, user IDs or request IDs on individual metric data points) belong on events (traces and logs).
Use the metrics migration as an opportunity to audit your metric attributes and move anything high-cardinality back to event data, where Honeycomb handles them well.
Billing
Moving to time series metrics changes how your metric usage is measured—in most cases, for the better.
How does billing change?
Metrics-as-events counted against your monthly event allotment.
Time series metrics are billed separately as data points, which means your metric data no longer competes with your traces and structured logs for event quota.
For most Free and Pro customers, moving to time series metrics will free up meaningful event headroom.
Your plan’s datapoint allotment is visible on the Usage page in your Honeycomb account.
Getting help
The right place to get help depends on your plan.
I am a Pro customer. How do I get support?
Pro customers can reach Honeycomb Support directly.
Open a support ticket and describe where you are in your migration: whether you need help understanding the new query model, troubleshooting a specific metric, or thinking through how to replace a complex metrics-as-events Board.
The support team is there to help you understand the new model.
I am a Free customer. Where can I get help?
Free customers have access to Honeycomb’s documentation and community resources.
The Honeycomb docs will have updated guidance on time series metrics, temporal aggregation, and the metrics query builder.
For deeper questions, the Honeycomb Community Slack (Pollinators) is an active place to ask.
What if the 6-month window isn’t enough time?
Reach out to Honeycomb Support as early as possible if you anticipate needing more time.
Don’t wait until the window is closing.
This timeline applies to Free and Pro plans only.
Enterprise customers on existing contracts are not subject to this deprecation window. 
