Honeycomb Alert Scribe with Claude Code
One alert is a small pipeline: read the trigger and the query behind it, create a query, start a result, keep reading that result until it has finished computing, then run the whole thing again with a group by. A result still in flight is not evidence and the figure inside the notification is one evaluation old. Claude Code carries sequences like that without cutting the wait short.
Watch it work before it's live
Run a staged conversation — no account needed. The agent handles it for real while a simulated world answers its tool calls; nothing touches real accounts, and nothing is actually sent.
checkout p99 over 800ms
The trigger evaluates P99(duration_ms) over five minutes against a threshold of 800. The evaluation that fired returned 2,140 at 14:07 UTC, against 310 at 13:30. The trigger has no group by of its own. The dataset carries service.name, http.route, tenant_id and app.cache_hit.
Set up in minutes
Using this template drops you into a guided setup. It asks exactly this, nothing else:
Connect Honeycomb
One sign-in. The agent acts through your account, scoped to what this template uses.
Connect Slack
One sign-in. The agent acts through your account, scoped to what this template uses.
Triage notes
How you want a fired trigger written up - the field worth grouping by in each dataset, the triggers you already know are noisy, plus the opening move you expect on a latency alert, on an error rate alert, and on a query that comes back with nothing in it.
Runs on Claude Code
Preselected for this page — connect your Claude Code account during setup, or switch to NoClick's built-in models with one click.
Watch it handle a test run
A staged conversation against a simulated world — then it’s live.
Why Claude Code for this agent
Polling until it finishes
Reporting a half computed result is worse than reporting nothing, because it looks like a measurement. Waiting properly is unglamorous and it is the step that makes the number trustworthy.
The second query is the point
The trigger gives one aggregate across everything. Rerunning it grouped is what turns that into a route, a service or a tenant somebody can go and open.
Before you fork
Two queries per alert. Does that hit our Honeycomb quota?
They go through the same query API your team uses from the interface, and it is two per fired trigger rather than any kind of polling loop against your data. The thing to watch is a noisy trigger, and your triage notes are where you record which ones are already known to be noisy so a note from one is not read as news.
Run it with a different agent
Put Honeycomb Alert Scribe to work on Claude Code
Free to start. Guided setup, a test run against staged conversations, and it's live.