SuperAPI AI Directory

datadog-dashboards

Deployment & operations

View repository

Updated 10-16 03:46

About this skill

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

# Category Prefix Covers
1 Purpose & Scope scope- Audience, the decision it drives, variables over duplication, when it should not be a dashboard
2 Grounding in the Account disco- Confirming metrics, tags, and facets exist before querying them
3 Query Semantics query- The queries that return a number and are wrong
4 Choosing the Widget widget- Matching question to visualization; the pairs that are not interchangeable
5 Dashboard JSON json- What widget validation cannot see or cannot explain
6 Layout & Readability layout- Datadog's own standard for structure, display types, titles, sizing
7 Shipping It ship- 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