Design and build Honeycomb queries: calculations, filters, breakdowns, visualization selection, granularity tuning, and anti-patterns. Activated by explicit mention of Honeycomb queries or /query invocation.
Designs and builds Honeycomb queries with calculations, filters, breakdowns, and visualization selection for dashboards and investigations.
npx claudepluginhub bendrucker/honeycomb-cliThis skill inherits all available tools. When active, it can use any tool Claude has access to.
references/api-types.mdreferences/examples.mdDesign effective Honeycomb queries for dashboards, investigations, and saved queries. Covers query specification, visualization selection, SLI-oriented patterns, and common anti-patterns.
{
"calculations": [{"op": "COUNT"}, {"op": "P99", "column": "duration_ms"}],
"filters": [{"column": "service.name", "op": "=", "value": "api-gateway"}],
"filter_combination": "AND",
"breakdowns": ["http.route"],
"orders": [{"column": "http.route", "order": "ascending"}],
"limit": 20,
"time_range": 7200,
"granularity": 60
}
COUNT, SUM, AVG, MAX, MIN, COUNT_DISTINCT, HEATMAP, CONCURRENCY, P001, P01, P05, P10, P20, P25, P50, P75, P80, P90, P95, P99, P999, RATE_AVG, RATE_SUM, RATE_MAX
=, !=, >, >=, <, <=, starts-with, does-not-start-with, ends-with, does-not-end-with, exists, does-not-exist, contains, does-not-contain, in, not-in
time_range: Relative window in seconds (default: 7200 = 2 hours)start_time / end_time: Absolute UNIX timestampstime_range, but not all threeSeconds per time bucket. Valid range: time_range / 1000 to time_range.
| Time range | Recommended granularity | Buckets |
|---|---|---|
| 10 minutes (600) | 10-30s | 20-60 |
| 2 hours (7200) | 60s | 120 |
| 24 hours (86400) | 300-600s | 144-288 |
| 7 days (604800) | 1800-3600s | 168-336 |
| 28 days (2419200) | 3600-14400s | 168-672 |
Choose chart types based on the data pattern, not the Honeycomb default (line graph).
| Value | Name | Best for |
|---|---|---|
line | Line graph | Continuous metrics with high cardinality over time (CPU, memory) |
tsbar | Time series bar | Time-bucketed counts and sparse data (errors, deploys, events) |
stacked | Stacked area | Showing composition/proportion over time (errors by type, traffic by service) |
stat | Stat card | Single headline number with sparkline (current p99, error rate) |
cbar | Categorical bar | Comparing values across groups, non-time-series (latency by endpoint) |
cpie | Categorical pie | Proportional breakdown of a total (traffic share by region) |
chart_indexWhen a query has multiple calculations, chart_index maps to the 0-based index in the calculations array. Set chart type per calculation:
{
"charts": [
{"chart_index": 0, "chart_type": "tsbar"},
{"chart_index": 1, "chart_type": "line"}
]
}
P50 as the baseline (median) and P99 for worst-case.line with overlaid_charts: true for P50/P99 overlay. The gap between P50 and P99 is the signal -- a widening gap indicates tail latency problems.HEATMAP panel below the percentile chart for distribution visibility. Heatmaps reveal bimodal distributions and outlier clusters that percentile lines hide.AVG on a boolean error column. In Honeycomb, AVG(bool) computes the proportion of true values -- this IS the error rate (0.0-1.0).line -- shows trend clearly without visual clutterservice.name or http.route to answer "where are errors coming from?" Do NOT break down by http.status_code -- individual status codes are too granular and produce noisy, unactionable charts.COUNTstacked bar when broken down by service or route -- clearly shows both total volume and composition. Use tsbar only for total count without breakdown.service.name, http.route, rpc.methodCOUNT_DISTINCT on the column of interestcbar for comparing across groups, stat for a single headline numberHEATMAP on a numeric columnRATE_SUM, RATE_AVG, or RATE_MAXline (shows trend direction clearly)When data arrives infrequently (webhooks, batch jobs, rare errors):
tsbar instead of line charts. Line graphs interpolate between points, creating misleading visual continuity.omit_missing_values: true to avoid flat zero lines between events.tsbar.limit in the query or aggregate differently.Structure queries around Service Level Indicators. An SLI is a ratio: good events / total events. Keep to five or fewer per service.
| SLI | Honeycomb calculation | Visualization |
|---|---|---|
| Availability | AVG(error) inverted (1 - error rate) | line |
| Latency | P50/P99 on duration_ms | line overlaid |
| Error rate | AVG(error) on boolean column | line |
| Throughput | COUNT | stacked by service |
| Freshness | MAX(age_seconds) or custom | line |
For SLO-aware dashboards, use compare_time_offset_seconds (e.g., 86400) to overlay current error rate against the previous day. This shows burn trajectory without requiring SLO-specific API access.
Use the Honeycomb MCP server to create and test queries. This works on all plans and doesn't require Enterprise API permissions.
honeycomb mcp call run_query -f dataset=<dataset> -f query_json='<json>'
honeycomb api -X POST /1/queries/<dataset> --input <query-file>.json
Note: piping JSON via stdin can fail if string values contain special characters (e.g., != in filter operators). Use --input with a file instead.
A "saved query" in the Honeycomb UI is a query annotation that references a query ID.
jq -n '{name: "Panel Title", query_id: "<query-id>"}' | honeycomb query annotation create --dataset <dataset> --file -
Expert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.