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]
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
Gap
Related: getsentry/sentry#116339 (per-issue event cap with keep-counting).
Requested by Colin Kawai.
--
View Junior Session [Sentry]