datadog-dashboards

v2026.09.24

Corrects the wrong defaults a model has when building Datadog dashboards, verified against Datadog's docs in July 2026. Use when creating, editing, or reviewing a Datadog dashboard — choosing widgets, writing metric/log/span queries, or emitting widget JSON. Covers the queries that render a plausible number and are still wrong — `.as_count()` is appended automatically in the graph editor but never through the API, so programmatic counts silently average; `p95` resolves only on distribution metrics, and averaging one is an average of averages; ratios need `.as_count()` on both sides or they divide interpolated averages. Also covers grounding queries in metrics that exist rather than invented names, wire type strings that diverge from UI names (Pie Chart is `sunburst`, Table is `query_table`), and Datadog's own layout standard. Assumes the Datadog MCP server is connected. NOT for Terraform or raw Dashboard API management, monitor and SLO authoring, or non-Datadog observability tools.

GitHub
安装命令
npx skhub add pproenca/datadog-dashboards
Markdown
SKILL.md

Datadog Dashboards

The decisions Datadog forces when you build a dashboard, and how to settle them. Every rule names the wrong default it corrects; there is no rule for what the model already gets right.

Pinned to a date, not a version. Datadog ships continuously, so every claim here was verified against docs.datadoghq.com in July 2026. Re-verify before trusting anything version-shaped — deprecations here (q, default, is_read_only, week_before()) still parse today.

Assumes the Datadog MCP server is connected (https://mcp.<site>/v1/mcp, toolsets=dashboards,widgets). Widget schemas are deliberately not restated in this skill — get_widget_reference returns them current at call time, and a copy here would go stale. If the server is not connected, set it up first (ship-endpoint-follows-the-site); this skill does not cover Terraform or raw API management.

When to Apply

Use this skill when:

  • Creating or editing a Datadog dashboard, or reviewing one someone else built — especially a board assembled programmatically rather than in the graph editor, which is where the .as_count() divergence bites
  • Writing any Datadog query destined for a widget: metric queries with space aggregators and modifiers, or logs / spans / rum queries with search + compute + group_by
  • Choosing between visualizations, or being handed a request that says "graph" but wants a ranking, a single number, or an error budget
  • A dashboard shows numbers nobody trusts, panels that render "No data", or a value that changes when the time frame changes
  • Asked for "a dashboard for X" with no stated audience — the interview in scope-ask-audience-and-decision runs before anything is built

This skill is NOT for:

  • Managing dashboards through Terraform or the raw Dashboard API (this skill assumes the MCP server)
  • Authoring monitors or defining SLOs — though scope-not-every-question-is-a-dashboard covers recognising when the request is one of those
  • Datadog instrumentation: agent config, tracer setup, or deciding which metrics to emit in the first place
  • Non-Datadog observability platforms — the query semantics here do not transfer

Rule Categories

#CategoryPrefixCovers
1Purpose & Scopescope-Audience, the decision it drives, variables over duplication, when it should not be a dashboard
2Grounding in the Accountdisco-Confirming metrics, tags, and facets exist before querying them
3Query Semanticsquery-The queries that return a number and are wrong
4Choosing the Widgetwidget-Matching question to visualization; the pairs that are not interchangeable
5Dashboard JSONjson-What widget validation cannot see or cannot explain
6Layout & Readabilitylayout-Datadog's own standard for structure, display types, titles, sizing
7Shipping Itship-Validate-and-smoke-test before writing; region endpoints

Quick Reference

1. Purpose & Scope

2. Grounding in the Account

3. Query Semantics

4. Choosing the Widget

5. Dashboard JSON

6. Layout & Readability

7. Shipping It

How to Use

Read a reference file when its decision comes up. Each rule names the wrong default it corrects, then shows the canonical form — with an incorrect/correct contrast only where the wrong way is a real trap.

Three shortcuts worth taking first:

  • Building a dashboard from a request? Run scope-ask-audience-and-decision, then disco-never-invent-metric-names, before emitting anything. Skipping either produces a board that is fluent and useless.

  • Reviewing a dashboard whose numbers look wrong? Start with query-append-as-count-explicitly and query-percentiles-require-distributions. Together they account for most Datadog panels that are confidently incorrect, and neither leaves a trace in the UI.

  • Porting dashboard JSON written before 2025? json-queries-and-formulas-not-q and json-template-variables-take-defaults are the deprecations that still parse, so nothing points you at them.

  • Section definitions — category structure and ordering rationale

  • Rule template — for adding new rules

  • AGENTS.md — auto-built table of contents across all rules

发现
标签

此技能尚未发布标签。

版本
最新版本元数据

版本

v2026.09.24

发布时间

2026年9月24日

分类

未分类

许可证

MIT

源路径

skills/.experimental/datadog-dashboards

默认分支

master

最新提交

cf93c57

Tree SHA

afbb575