Reruns the fired trigger's own query around the alert window and posts one Slack note carrying the threshold, the number it actually returned, and the service or route holding most of it.
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.
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.
Choose which agent runs it
NoClick's built-in models work out of the box — or bring Claude Code, Codex, and other coding agents on your own subscription.
Watch it handle a test run
A staged conversation against a simulated world — then it’s live.
A fired trigger tells you an aggregate crossed a line, which is the least useful shape that fact ever takes: nobody wants to know that p99 is high, they want to know whose p99 it is. This agent runs the trigger's own query again around the alert window, runs it once more grouped by the field you care about, and posts one Slack note with the threshold, the real value and the two or three groups holding it. It never says why, because the query cannot, and it leaves every trigger exactly as you wrote it.
What does it need access to?
A Honeycomb key that can read triggers and run queries in the environment you point it at, the trigger notifications routed into this workflow, and a Slack channel. Queries go through the same API your team already uses, two per alert, one for the window and one for the breakdown. Your triage notes go in as a variable.
Does creating queries clutter our environment?
The queries it creates are the same throwaway objects the interface creates every time somebody presses run, and they are never saved into a board or a collection. Nothing existing is modified, no trigger, saved query, SLO or derived column, which also means the worst mistake available to it is a note people scroll past.
How is this better than the notification Honeycomb already sends?
The notification carries the number that crossed and a link into the interface. This carries the number as it stands when the note is written, the group holding it, and the first check your own notes prescribe, delivered where the team already is. It genuinely cannot tell you a cause, so treat it as the first two minutes of an investigation done for you rather than as an answer.
Free to start. Guided setup, a test run against staged conversations, and it's live.