dashboard-review

dashboard-review

When to use

Use this skill when tasks include:

• reviewing a PR that modifies Kibana dashboard JSON files
• comparing dashboard changes between branches
• summarizing what changed in dashboard exports
• checking dashboard changes against the official dashboard guidelines

When not to use

Do not use this skill as the primary guide for:

• creating new dashboards or exporting them from Kibana (dashboard-guidelines)
• dashboard naming conventions and file layout (dashboard-guidelines → references/kibana-assets-layout.md)
• package-wide command orchestration (elastic-package-cli)
• test suite selection (integration-testing)

Prerequisites

kbdash must be installed:

go install github.com/efd6/kbdash@latest

Lines prefixed with [!] in the output are warnings about potential issues in the dashboard JSON (consistency mismatches, incomplete extraction, parse errors). Run kbdash -h for a description of each warning type.

Review procedure

Read references/review-procedure.md for the full step-by-step workflow. The high-level flow is:

1. Identify changed dashboard files (added, removed, modified).
2. Extract before/after descriptions with kbdash.
3. Compare descriptions and classify changes as meaningful or cosmetic.
4. Verify suspected issues against the raw JSON before reporting.
5. Format output as one section per dashboard with bullet-pointed changes.
6. Check guideline compliance on added or modified dashboards.

Guideline compliance checks

After summarizing changes, check the final state of every added or modified dashboard against the official dashboard guidelines. Report violations in a "Guideline notes" subsection after the change summary for each dashboard.

Check for these issues:

• TSVB panels: Flag any visualization panel using TSVB. The guidelines require Lens for all new visualizations. Migrating existing TSVB to Lens is encouraged.
• Missing dataset filter: Each visualization should filter on data_stream.dataset or an equivalently specific scope. Flag panels that query broad index patterns (metrics-*, logs-*) without scoping.
• By-reference visualizations: Visualization and lens panels should be embedded by value. In the raw JSON, references entries with a panelRefName indicate by-reference panels. Flag these only when the reference type is visualization, lens, or map. Saved searches (search type) are inherently referenced and should not be flagged.
• Deprecated input controls: The input-control-vis type is deprecated. Dashboard-native controls should be used instead.
• Package-name title prefix: Panel titles matching [<Package Name> ...] create unnecessary repetition. Flag these.
• Broad wildcard filters: Filters using unscoped -* patterns without further qualification are a performance concern.
• High panel count: If a dashboard has more than roughly 20 panels, note it. The guidelines recommend splitting across dashboards and linking with drilldowns.
• Queries on event.dataset instead of data_stream.dataset: Saved-object queries (dashboards, saved searches, packaged ML job datafeeds) must filter on data_stream.dataset. Some inputs (e.g. packetbeat) never set event.dataset, so an event.dataset filter silently matches nothing. Flag every saved-object query in a diff that renames or re-maps fields.
• YAML dashboard sources out of sync: When a package keeps YAML dashboard sources in _dev/shared/kibana/*.yaml (compiled to kibana/dashboard/*.json with kb-dashboard), BOTH must be committed and in sync. Flag JSON-only edits when a YAML source exists for that dashboard.
• Regeneration diffs: A recompile PR is expected to change only state.adHocDataViews, state.internalReferences, and per-layer index keys (the ES|QL/Discover fix on Kibana 9.3+). Diffs beyond those keys in a "regenerate" PR deserve inspection.
• Missing Kibana asset tags: New content-pack dashboards are expected to carry Kibana asset tags — note their absence (LOW).