Create a metric from observed errors or tool calls

After noticing something worth tracking — an error spike, or slow/hot agent tool calls — users need a way to create a metric from that signal and keep monitoring it over time.

Current behavior

• Error occurrence counts come from stored error events. Dropping or filtering events loses count fidelity (#116339).
• Agent and tool activity is available as spans and product surfaces, but there is no path to pick a specific observed error or tool call and turn it into a metric for ongoing monitoring.
• Existing "derived metrics" work is formula/equation composition over metrics already in the system (for example #106873, #112628), not creating a metric from something the user just observed.

Gap

• Errors: after a spike or noisy issue, teams want to start tracking frequency as a metric without storing every full event or building custom instrumentation.
• Agent monitoring: after seeing a specific tool call that is slow or frequent, teams want to create a metric from it and monitor that signal going forward.

Related: getsentry/sentry#116339 (per-issue event cap with keep-counting).

Requested by Colin Kawai.

--

View Junior Session [Sentry]

Start by reviewing the current behavior and gap described in this issue, then compare the related work in #116339, #106873, and #112628. The issue does not name an implementation entry point or tests. Done means users can create a persistent metric from an observed error or agent/tool call and monitor it without storing every full event or adding custom instrumentation.