feat: Add dashboard and widget commands

[betegon]

Summary

Add dedicated commands for managing Sentry dashboards and widgets. Currently, the only way to create or manage dashboards is through the generic sentry api command with hand-crafted JSON payloads, which provides no guardrails or validation.

Motivation

Dashboards and their widgets are a core part of the Sentry product, but the CLI has no first-class support for them. Today, creating a dashboard looks like this:

# Write a JSON payload by hand
cat > dashboard.json << 'PAYLOAD'
{
  "title": "My Dashboard",
  "widgets": [
    {
      "title": "Transaction Duration (P95)",
      "displayType": "line",
      "queries": [{
        "fields": ["p95(transaction.duration)"],
        "aggregates": ["p95(transaction.duration)"],
        "columns": [],
        "conditions": "event.type:transaction"
      }]
    }
  ]
}
PAYLOAD

# Send it through the raw API command
sentry api organizations/{org}/dashboards/ -X POST --input dashboard.json

The API accepts the payload and returns success, but the widgets may fail to render in the Sentry UI with GET /organizations/{orgSlug}/events-stats/ 400 errors — with no indication at creation time that anything was wrong.

Vision

First-class commands for viewing and managing dashboards and widgets. The command structure could live as a top-level group (sentry dashboard, sentry widget) or nested (sentry dashboard widget) — to be decided during implementation.

Example usage (illustrative, not prescriptive):

# Dashboards
sentry dashboard list [<org>] [--json]
sentry dashboard view <dashboard-id> [--json] [-w]
sentry dashboard create <title> [<org>] [--json]
sentry dashboard delete <dashboard-id>

# Widgets
sentry widget list <dashboard-id> [--json]
sentry widget add <dashboard-id> --title "P95 Latency" --display-type line --query "p95(transaction.duration)" ...
sentry widget delete <widget-id>

Key considerations

Widget query validation

The biggest pain point today is that the Sentry API does not validate widget queries/filters at creation time. You can create a dashboard that looks successful, but every widget shows a 400 error in the UI because of:

• Invalid or incompatible conditions filter syntax
• Mismatched displayType and dataset (e.g., Issues dataset only works with table)
• Missing or incorrect aggregates/columns/fields alignment
• orderby referencing fields not present in the query
• big_number widgets with more than one aggregate

The CLI should validate widget configurations before sending them to the API, or at minimum provide a dry-run mechanism that checks query validity.

Other considerations

• Follow existing CLI patterns (--json, -w/--web, context resolution)
• The objects inside a dashboard are called widgets — each widget has a display type, one or more queries, and a grid layout
• PUT on dashboards replaces the entire widget list — omitted widgets get deleted
• Widgets have different dataset types (error-events, transaction-like, issue, release, spans) with different constraints per type

[kunalsentry]

Side note on platform querying: it would be helpful to have public documentation regarding the syntax, datasets & full capabilities that customers/agents could reference in general. Currently we have this which isn't comprehensive.

[bcoe]

@betegon stoked for this functionality. We want something along these lines in product... it would be awesome to pilot with the CLI, learn from it, and then bring in similar functionality.

Side note on platform querying: it would be helpful to have public documentation regarding the syntax

As @kunalsentry says, we don't have a good comprehensive guide of everything possible in the query language, or the widgets supported by each dataset. Keep in mind, dashboards support multiple datasets span, logs, metrics, and mobile builds all have similar capabilities; errors, issues, and releases use a different underling database and have different capabilities.

For understanding query language capabilities, here are some additional resources:

• For creating span-based dashboards, Trace Explorer documentation is likely a good starting point.
• For creating error-based dashboards, Query Builder is a good starting point

...another approach

We have dozens of sentry-built dashboards available in the codebase, these dashboards include JSON describing:

• Queries.
• Available widgets.
• Advanced features, like inter-dashboard linking.

Could you run an LLM against this folder structure, or maybe this folder structure and some additional resources (like those linked above) and backwards engineer some of the capabilities (maybe creating a JSON schema, or something along those lines, that could help guide the CLI?).