the cli can't currently query aggregate data to verify spikes directly, which pushes it toward slow issue-by-issue/event-by-event workarounds.
- use case: inspect whether a reported spike is real from the cli, ideally by querying aggregate results instead of fetching many individual issues or events in a loop
- likely desired capability: query discover-style aggregates or event stats from the cli
- concrete example shared: using discover for errors with fields like
title, grouped over time with metrics such as count() and count_unique(user) to inspect a spike window
- current limitation observed: there doesn't seem to be a cli path for this today, so the fallback was pulling down up to a thousand issues individually, which is slow and awkward for this workflow
- related context from the thread: a relative
--period 1h query came back empty, so explicit UTC windows were used instead to tie comparisons to the actual spike window
Action taken on behalf of Josh Ferge.
the cli can't currently query aggregate data to verify spikes directly, which pushes it toward slow issue-by-issue/event-by-event workarounds.
title, grouped over time with metrics such ascount()andcount_unique(user)to inspect a spike window--period 1hquery came back empty, so explicit UTC windows were used instead to tie comparisons to the actual spike windowAction taken on behalf of Josh Ferge.