This content is intended to help Honeycomb customers understand how we define and calculate usage of the product for billing purposes. Our pricing plans are based primarily on events per month, and the features described here are designed to help teams understand how their usage of Honeycomb is evolving over time. This page also defines the conditions that can lead to overages and behavior of the product when a team exceeds their monthly event limit.
An event is a collection of information about what it took to complete a unit of work. For example, accepting an HTTP request and doing the required work and then passing back a response. Events are the base unit of information managed within Honeycomb.
In the case of trace data, each span in a trace is counted as an event by Honeycomb.
Each SpanEvent or Link (in OpenTelemetry and OpenCensus) is counted as an event.
A span represents a unit of work similar to other types of events, whereas a trace is a complex request that is comprised of a number of these units.
Thus a trace comprised of 150 spans will be counted in Honeycomb as 150 events.
For information about the format and size of events that are accepted by Honeycomb, please refer to documentation for the Honeycomb Event API and OpenTelemetry.
A team’s usage of Honeycomb is measured in events per month (EPM). All Honeycomb plans (Free and Pro) have an EPM limit associated with them at the team level, and all successful events ingested by Honeycomb count against this limit. Events that are rejected due to operational rate limiting, excessive size, or being malformed do not count against the EPM limit. Events that are sampled before being ingested by Honeycomb, such as via Beelines or other application-specific sampling methods, do not count against the EPM limit.
Based on the EPM limit, Honeycomb calculates a daily event target (EPM divided by 30.4). Both the EPM limit and the daily event target are displayed on the Usage tab under the Team Settings page. All event counts are based on calendar month, irrespective of when a team’s billing renewal date may fall.
Enterprise plans have an EPM limit based on the events per year (EPY) associated with the annual plan.
Honeycomb will notify team owners via email when they are trending toward a possible overage based on their EPM limit. If the EPM limit is exceeded for one month, team owners will receive notification about the overage at the beginning of the following month. Should the EPM limit be exceeded for a second consecutive month, team owners will receive another notification, this time including a warning that their incoming events will be throttled if the overage is not corrected.
After the second month of overage, team owners will have 10 days to correct their plan overage. The overage can be corrected by upgrading the team to a higher capacity plan, or by changing the amount of data that is sent to Honeycomb. If the rate of incoming events is not reduced to be below the daily target, Honeycomb will begin throttling events. The Honeycomb Event API will randomly accept only 1 of every 10 events; the remaining 9 events will be rejected by the API and will not be ingested or stored in Honeycomb. Throttling will continue until the rate of incoming events for the team 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!
Honeycomb will surface a warning (yellow) state and a danger (red) state based on historical event throughput for a team. The colors are shown on the usage radial on the left-hand navigation menu.
The usage radial will be completely green when event throughput is trending below the team’s monthly event limit. A warning state is triggered when a team is trending toward an overage based on event throughput in the current calendar month, or when the team has exceeded their EPM limit for one month as described above in the Overages section. A danger state is triggered when a team has been over its EPM limit for two consecutive months.
We understand that sometimes the most interesting incidents can produce a high volume of traffic and we want Honeycomb 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. The events in excess of the daily event target will not be counted against the team’s EPM limit. As an example, if a team has a daily event target of 30 million events and one day sends 90 million events, the excess 60 million events will not be counted against the team’s EPM limit. Burst protection can be triggered up to three times in a calendar month.
When burst protection is triggered, the team owner will receive an email notification. The effect of burst protection will also be visible on the Usage tab of the Team Settings page in Honeycomb. While burst protection events are not counted against a team’s EPM limits, they are successful events and will appear in the Per-Environment and Per-Dataset Breakdown sections.
All Honeycomb datasets include 60-day fixed retention. The retention period is calculated based on the date the events are ingested by Honeycomb, and not based on timestamps within the data. Should a team require data to be retained for a shorter period or deleted for any reason, contact Honeycomb Support for assistance.
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.
Normally, Honeycomb weights calculations based on sample rates, but there are times when it is useful to carry out operations without taking sample rate into account. For example, a Team Owner might wish 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, visit the Usage tab on the Team Settings page, and select the “Usage Mode” button on the appropriate row in the Per-environment Breakdown table.
In Usage Mode, the user has access to the field Sample Rate, which reflects what Honeycomb interprets as the sample rate; and COUNT (and all other calculation operations) are unweighted.
This can help diagnose errors in sending sample data, and to better understand the relative changes in sampling strategies. For example, it can be useful to monitor the level at which a dynamic sampler is sending data.
