honeycomb

Set up the Honeycomb MCP server connection for Claude Code

Use this agent when the user needs an autonomous, multi-step investigation of a production issue using Honeycomb. Examples: <example> Context: User received a PagerDuty alert about high latency user: "Our checkout API is slow, can you investigate using Honeycomb?" assistant: "I'll use the honeycomb-investigator agent to run a systematic investigation." <commentary> User needs autonomous investigation using Honeycomb MCP tools. The agent will prime context, run queries, use BubbleUp, trace analysis, and report findings. </commentary> </example> <example> Context: User sees errors in production after a deployment user: "We deployed v2.5 and errors spiked. Investigate what went wrong in Honeycomb." assistant: "I'll launch the honeycomb-investigator to analyze the deployment impact." <commentary> Multi-step investigation needed — query for errors, BubbleUp to compare versions, trace analysis to find root cause. Agent orchestrates the full workflow. </commentary> </example> <example> Context: SLO budget is burning fast user: "Our checkout SLO is burning budget fast. Can you figure out what's going on?" assistant: "I'll launch the honeycomb-investigator to analyze the SLO burn and identify the cause." <commentary> SLO-driven investigation. Agent will check SLO status, identify contributing errors/latency, use BubbleUp to find differentiators, and trace affected requests. </commentary> </example>

Use this agent when the user wants to improve their application's observability by analyzing their codebase against what Honeycomb actually receives. This agent autonomously scans code, queries Honeycomb for existing coverage, and produces a prioritized gap analysis with ready-to-apply code. Unlike the otel-instrumentation skill (SDK guidance), this agent reads the user's actual code and compares it against live Honeycomb data. Examples: <example> Context: User wants to know what they should instrument next user: "What's missing from our instrumentation? We have basic tracing but I feel like we're not getting enough detail." assistant: "I'll use the instrumentation-advisor agent to analyze your codebase against your Honeycomb data." <commentary> Agent will scan the codebase for uninstrumented code paths, query Honeycomb for existing field coverage, and produce a prioritized gap report with code suggestions. </commentary> </example> <example> Context: User wants to add observability to a specific service user: "Can you instrument our checkout service? It's in Go and we have basic OTel but no custom spans." assistant: "I'll launch the instrumentation-advisor to analyze the checkout service and add custom instrumentation." <commentary> Agent will read the service code, identify high-value operations (HTTP handlers, DB calls, business logic), check what Honeycomb already sees, and write instrumentation code. </commentary> </example> <example> Context: User is debugging and notices gaps in their traces user: "Our traces are missing context — I can't tell which user or tenant is affected. Can you fix that?" assistant: "I'll use the instrumentation-advisor to find where to add user and tenant context to your spans." <commentary> Attribute enrichment task. Agent will find where user/tenant info is available in code, check which attributes Honeycomb already has, and add span attributes at the right points. </commentary> </example>

Step-by-step guide for migrating from Honeycomb Beelines (End of Life) to OpenTelemetry instrumentation. Trigger phrases: "migrate from Beelines", "upgrade from Beeline to OpenTelemetry", "migrate to OTel", "replace Beelines", "Beeline end of life", "Beeline EOL", "switch from Beeline to OTel", "migrate Go Beeline", "migrate Python Beeline", "migrate Node Beeline", "migrate Java Beeline", "migrate Ruby Beeline", "W3C trace headers", "W3C propagation", "incremental migration to OpenTelemetry", or any request about migrating from Honeycomb Beelines to OpenTelemetry SDKs.

Design and then create a board (dashboard) in Honeycomb with queries and SLOs. Trigger phrases: "create a board", "make a board", "build a dashboard", "create a Honeycomb board", "make a dashboard in Honeycomb", "set up a board", "dashboard for my service", "visualize service health", "golden signals dashboard", "set up monitoring board", or any request to design and create or build a Honeycomb board or dashboard.

How to query OpenTelemetry metrics datasets in Honeycomb correctly. Metrics datasets follow different rules from trace/event datasets — many operations (bare COUNT, RATE_SUM, RATE_AVG, RATE_MAX, CONCURRENCY) are forbidden, temporal aggregation is automatic, and each metric has its own attributes. Use this skill when querying a metrics dataset (gauges, counters, histograms, sums), asking about temporal aggregation (RATE, INCREASE, SUMMARIZE, LAST), finding the metrics dataset or discovering metric names and attributes, debugging unexpected metrics query results, or querying infrastructure metrics like CPU, memory, disk I/O, or network stats. Do NOT use for instrumenting metrics (use otel-instrumentation), querying event datasets with "metrics" in their name, or conceptual questions (use observability-fundamentals).

First principles behind observability — wide events, high cardinality, the core analysis loop, events vs metrics vs logs, and how instrumentation connects to debugging outcomes. Grounds recommendations in first principles rather than tool-specific how-to. Trigger phrases: "what is observability", "why observability", "why Honeycomb", "events vs metrics vs logs", "events vs metrics", "events vs logs", "metrics vs logs", "why wide events", "what is high cardinality", "core analysis loop", "observability vs monitoring", "what is dimensionality", "explain observability", or any conceptual question about observability or why Honeycomb's approach differs from traditional monitoring.

Provides guidance on OpenTelemetry SDK setup, custom instrumentation, and sending data to Honeycomb. Trigger phrases: "instrument my app", "add tracing", "set up OpenTelemetry", "configure OTel", "add custom spans", "add attributes to spans", "send traces to Honeycomb", "set up OTLP", "configure sampling", "add span events", "add span links", "set up tracing for [any language]", "configure the OTel Collector", or any request about OpenTelemetry SDK setup, custom instrumentation, or sending data to Honeycomb.

2 hooks across 2 events