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.

Guide for retrofitting OpenTelemetry into an existing, uninstrumented application. Trigger phrases: "migrate existing app to OTel", "add OpenTelemetry to existing project", "retrofit OTel into my codebase", "thread context through my code", "context propagation", "bridge Prometheus metrics to OTel", "logging bridge", "migrate logging to OTel", "slog bridge", "logback bridge", "verify my instrumentation", "traces are disconnected", "orphaned spans", "migrate to OpenTelemetry", "OTel migration plan", "how do I sequence an OTel migration", "add tracing to existing code", "refactor for context propagation", "Fiber context gotcha", "keep existing logging working with OTel", "add OTel without breaking Prometheus", "bridge existing metrics", "coexist with existing monitoring", or any request about retrofitting OpenTelemetry into an existing application. This skill is for migrating existing codebases, NOT greenfield instrumentation (use otel-instrumentation) or Beeline-specific migration (use beeline-migration).

Structured workflows for investigating production issues in Honeycomb — the sequence of tool calls (context priming, broad query, BubbleUp, trace analysis, verification) and how to chain results between steps to reach root causes. Trigger phrases: "investigate production issue", "debug latency spike", "find root cause", "use BubbleUp", "analyze traces", "debug an outage", "why is my API slow", "errors are increasing", "health check", "SLO burning", or any request to investigate or debug production problems.

Opinionated guidance for constructing and interpreting Honeycomb queries on trace and event datasets — operation selection (percentiles not AVG, HEATMAP for distributions), relational field patterns (root., parent., any., none.), calculated fields, query math, and result interpretation (P99/P50 ratios, heatmap bands, TOTAL/OTHER rows, raw JSON via query_result_json). Use this skill when the user wants to query spans, traces, or log/event data in Honeycomb — requests like "show me latency", "error rate", "find slow requests", "find outliers", "interpret results", "relational fields", "calculated fields", or "download raw results". This skill covers all dataset types except metrics datasets (dataset_type=metrics) — for those, use metrics-queries instead.

Decision heuristics for interpreting Honeycomb SLO compliance, budget burn rates, and trigger status — what the numbers mean and what action to take, including detecting misconfigured SLIs, deciding when to freeze deploys vs page on-call, and designing burn alert thresholds. Load this skill before calling get_slos or get_triggers. Trigger phrases: "check our SLOs", "are we meeting our SLOs", "which SLOs are healthy", "is the error budget OK", "are any alerts firing", "what's the burn rate", "set up an SLO", "create a trigger", "configure alerts", "set up burn alerts", "check trigger status", "starting on-call", "reliability picture", "should we freeze deploys", "is this SLO misconfigured", "are we within budget", "SLO is broken", "budget is negative", or any request about service level objectives, error budgets, burn rates, or alerting in Honeycomb.

2 hooks across 2 events