[manessaraj]

Adds sentry event analytics, which reports events Sentry received but dropped before storage (rate-limited, filtered, invalid, abuse, client-discarded, cardinality-limited), one row per outcome and reason with each slice's share of total volume. It is the CLI counterpart to the find_dropped_events MCP tool, so an agent or a person working headless can see data-fidelity gaps without the web UI.

This reopens the work previously attempted in #1579, redone from scratch. The earlier attempt duplicated the dropped-events schema and dataset handling inside the CLI, which drifted from the MCP implementation and drew repeated review. The redo instead reuses the now-shared pieces that landed since then — the buildDatasetParser dataset map in lib/datasets.ts (so metrics normalizes to tracemetrics at parse time) and the find_dropped_events MCP feedback on response shape and tags — and builds on the standard command, target, and completion primitives rather than hand-rolled ones. The schema treats tags as optional, matching the endpoint and the MCP tool.

Verified end-to-end against production (project 1): the command resolves the project, fetches dropped events, and renders both the grouped human table and the JSON array, across the errors and spans datasets.

Refs DAIN-1940

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
sentry-local	Skipped		Nov 5, 2026 10:28am UTC

[linear-code]

DAIN-1940

[sentry-junior]

First-pass review on behalf of @BYK, checked against his feedback on #1579 and #1559 and the recent CLI standardisation work (reviewed at 870b28e).

Most of the earlier feedback is addressed. The name is now event analytics. Examples moved to docs.examples. Datasets go through the shared buildDatasetParser. The JSON output is flat rows with an item schema, so --fields outcome,reason,events works. The project ID is resolved strictly through fetchProjectId. Nice work on the redo.

Requesting changes for these:

• @sentry/api already has this endpoint. lib/api/dropped-events.ts says it is "Not yet in @sentry/api", but listOrganizationEventsDropped, ListOrganizationEventsDroppedResponse and vListOrganizationEventsDroppedResponse are all in the catalog's @sentry/api. packages/cli/AGENTS.md says to use the SDK types instead of redundant Valibot schemas, and BYK made the same point on #1559 ("we should use them from there not repeat types across repos"). The local response schema in types/dropped-events.ts duplicates the SDK's.
• The output schema is in its own module. AGENTS.md says src/output-schemas/ has one module per top-level command, so DroppedEventRowSchema belongs in output-schemas/event.ts. Its API fields (outcome, reason, category, tags) should come from the generated valibot entries, as project.ts does with vOrganizationProjectResponseDict.item.entries.
• --period is back to a local 24h default. The earlier commit that switched it to LIST_PERIOD_FLAG / PERIOD_ALIASES was lost in the force-push. BYK asked on #1559 for the default to match the rest of the CLI, and attribute, span, trace, replay and agent-conversation list all use the shared 7d flag.

I'm pushing a commit for all three right after this review:

• getDroppedEvents calls listOrganizationEventsDropped through getOrgSdkConfig + unwrapResult, like lib/api/issue-tags.ts.
• types/dropped-events.ts and output-schemas/dropped-events.ts are gone. The row schema lives in output-schemas/event.ts, built from vListOrganizationEventsDroppedResponse, and outcomeLabel moved into the formatter.
• Sentry only added tags in getsentry/sentry#127850. The summarizer still defaults them to [] for older self-hosted servers, and a formatter test covers that.
• --period uses the shared flag again. The skill reference is regenerated.

Still on you (@manessaraj): "analytics" only shows drops. On #1579 BYK asked to note adding accepted and other volumes, so that this becomes a real analytics command. The response already includes acceptedEvents, and share is computed against them, but they never appear in the output, and the PR doesn't link a follow-up. Either show the accepted total (for example as a row or a header line), or open a ticket and link it here.

The event, dropped-events API, and formatter tests pass with the fix commit, along with CLI typecheck and repo lint. I didn't run the full suite.

[BYK]

Jr is right :D

[sentry-junior]

On behalf of @BYK: I pushed f536c4c, which takes care of the last open item from the review ("analytics" only showing drops).

• Accepted volume is now the first row. Sentry returns it with outcome and reason accepted and empty tags. The drop rows follow it, in the same order as before. share is still each slice's fraction of accepted + dropped, so the shares now add up to 100%.
• In human output, accepted is one header line (Accepted: 9,500 (95.00%)) with no reason table. Each drop outcome keeps its header and table.
• The No dropped events for <org>/<project>. hint now also shows when the only rows are accepted ones.
• DroppedEventRow*, summarizeDroppedEvents and formatDroppedEvents are renamed to EventOutcome*, because the rows aren't only drops anymore. The file names stay the same since they match the events-dropped endpoint.
• The brief, description, schema field descriptions and skill reference are updated and regenerated.

@manessaraj, if you'd rather show accepted a different way (for example as a header line only, with no JSON row), say so and I'll change it.

Verified: CLI tsc, repo pnpm run lint, and the event + formatter tests pass, including new tests for accepted ordering, rendering and the accepted-only hint. In the full CLI unit run, 11 tests fail (permission, auth-message and oauth tests). The same tests fail on the previous head without this change, so they're from the sandbox and not this PR.

did on behalf of me, now we're good