Honeycomb wants you to understand your costs and be able to track how your team’s usage of Honeycomb is evolving over time.
Events are the base unit of information managed within Honeycomb. Honeycomb measures a Team’s usage in events per month (EPM).
All Teams on Free and Pro pricing plans have a specific associated EPM limit. For Teams on Enterprise pricing plans, we calculate the associated EPM limit based on the events per year (EPY) for their annual plan.
An event is a collection of information about what it took to complete a unit of work. For example, accepting an HTTP request, doing the required work, and then passing back a response counts as one event.
In traces, which are complex requests that comprise many spans, each span represents a unit of work, so Honeycomb counts each span in a trace (SpanEvent or Link in OpenTelemetry and OpenCensus) as an event.
For example, Honeycomb counts a trace that contains 150 spans as 150 events.
To learn more about the format and size of events that Honeycomb accepts, visit Honeycomb Event API and OpenTelemetry.
Events that count against the EPM limit include all successful events ingested by Honeycomb.
Events that do not count against the EPM limit include:
Based on the EPM limit, Honeycomb calculates a daily event target (EPM divided by 30.4). We base all event counts on calendar month, regardless of when a team’s billing renewal date may fall.
You can see both your EPM limit and your daily event target in the Honeycomb UI under Team Settings > Usage.
For Teams on all pricing plans, we surface a usage state indicator in the Honeycomb UI. You can see your Team’s warning state in the left-hand navigation menu, next to the Usage menu item. For teams that do not have predicted overages, the usage state indicator is OK (green).
For Teams on Free and Pro pricing plans that are in other states of overage, we handle overages in the following ways:
| Status | Usage State | Response |
|---|---|---|
| A team is trending toward a possible overage | Warning (Yellow) | We notify team owners via email. |
| A team exceeds its EPM limit for one month | Warning (Yellow) | We notify team owners via email at the beginning of the following month. |
| A team exceeds its EPM limit for a second consecutive month | Danger (Red) | We notify team owners via email and warn them that their team’s incoming events will be throttled if they do not correct the overage within 10 days. They can correct the overage by upgrading their team to a higher capacity plan or by changing the amount of data they are sending to Honeycomb. |
| After the 10 days, a team’s rate of incoming events continues to be above the daily target | Warning (Red) | Honeycomb will begin throttling events. The Honeycomb Event API will randomly accept only one of every ten events; the API will reject the remaining nine events, which will not be ingested or stored in Honeycomb. Throttling will continue until the team’s rate of incoming events is under the daily event target for at least 72 hours. |
If you receive a notification that your team is going to be throttled, please contact us if we can help you in any way. Throttling events is a last resort, and we want to help you avoid it if we can!
We understand that the most interesting incidents can produce a high volume of traffic, and we want to be there for you.
When the unexpected happens and creates a flood of data (more than 2x the daily event target), Honeycomb will automatically trigger burst protection and will not count events in excess of your daily event target against your team’s EPM limit. For example, if a team has a daily event target of 30 million events and sends 90 million events to Honeycomb in one day, Honeycomb will not count the excess 60 million events against the team’s EPM limit.
When burst protection is triggered for a Team, we will notify team owners via email. You will also be able to see the effect of burst protection in the Honeycomb UI under Team Settings > Usage. While we do not count burst protection events against a team’s EPM limits, these events are successful events and will appear in the Per-Environment and Per-Dataset Breakdown sections.
Burst protection can be triggered up to three times in a calendar month.
All Honeycomb datasets include 60-day fixed retention. We calculate the retention period based on the date the events are ingested by Honeycomb rather than on the timestamps within the data.
When a team changes their Honeycomb plan selection (upgrade from Free to Pro, downgrade from Pro to Free, and so on), Honeycomb will retain the team’s existing data up to the 60-day retention period.
If your team wants us to retain your data for a shorter period of time or delete it for any reason, contact Honeycomb Support for assistance.
Normally, Honeycomb weights calculations based on sample rates, but sometimes you may find it useful to carry out operations without taking sample rate into account. For example, you might want to know how many actual events are coming in for each category for a dynamic sampler.
Usage Mode provides a query builder that evaluates queries in an unweighted mode where sample rate does not figure into the calculations. To access Usage Mode, navigate to Team Settings > Usage in the Honeycomb UI, and select the Usage Mode button on the appropriate row in the Per-environment Breakdown table.
In Usage Mode, users have access to the Sample Rate field, which reflects what Honeycomb interprets as the sample rate, and COUNT (and all other calculation operations) are unweighted.
These changes can help diagnose errors when sending sample data, and can help teams to better understand relative changes in their sampling strategies. For example, you may find it useful to monitor the level at which a dynamic sampler is sending data.
