Datadog Ecosystem

Datadog is the infrastructure and service observability route when work involves logs, metrics, traces, dashboards, monitors, synthetics, CI visibility, or sourcemap upload. Source: Ecosystem Capability Coverage, 2026-06-27; Skill Resolver, 2026-06-27

When To Use This

Use Datadog when the question is operational telemetry across services, traces, metrics, logs, monitors, or CI/test visibility. Use Sentry for grouped application exceptions and PostHog for product analytics. Source: Skill Resolver, 2026-06-27

Decision Matrix

Core Model

Datadog is for service and infrastructure observability. It should connect telemetry to operational ownership, not become a dumping ground for every event the app can emit. Source: Observability Architecture, 2026-06-27

Routing Summary

Preferred order: Datadog MCP for logs, metrics, traces, dashboards, and monitors; ddsetup/Datadog skills when MCP/toolsets need setup; datadog-ci for CI visibility, synthetics, sourcemaps, and test metadata. Source: Skill Resolver, 2026-06-27; config/capability-harvest-seeds.json

Failure Modes

• Creating dashboards without runbook ownership.
• Alerting on internals instead of user-visible symptoms.
• Mixing product analytics with service health.
• Running broad telemetry queries without time and environment bounds.

Verification Path

Confirm org/site/project context before writes. For CLI work, use datadog-ci read/version/preflight where possible. For telemetry work, capture query bounds, result sample, and any monitor/dashboard ID. Source: config/capability-harvest-seeds.json; Skill Resolver, 2026-06-27

---

Timeline

• 2026-06-27 | Canonical ecosystem page created to promote Datadog from partial coverage into observability pack/routing ownership. Source: User request, 2026-06-27; Ecosystem Capability Coverage