Search and VIEW log entries. Returns paginated results.

IMPORTANT: Use this ONLY when you need to VIEW log content for debugging. For COUNTING logs or unique values, use count_logs or count_unique_values instead - they are much faster and lighter since they never fetch raw log content.

Use this when:

• Need to view actual log messages and details

• Debugging specific issues

• Investigating error details

DO NOT use for:

• Counting logs (use count_logs)

• Counting unique sessions/users (use count_unique_values)

• Statistical analysis (use aggregate_logs_by_field)

Get complete details of a specific log entry.

Use this when: need full information about a particular log (after searching).

Count logs matching a query WITHOUT fetching all data (fast & lightweight).

PREFERRED for counting events - much faster than search_logs, which should never be used just to count results.

Use this when:

• "How many errors happened?"

• "Count logs for a service"

• Need a number, not log content

Count UNIQUE values of a field (distinct count / cardinality).

PERFECT for counting unique sessions, users, IPs, etc. Much more efficient than fetching all logs with search_logs and counting distinct values client-side.

Use this when:

• "How many unique users/sessions?"

• "Count distinct values"

• "How many different X?"

Aggregate and group logs by a field with statistics (fast, no raw data transfer).

PERFECT for analytics, charts, and dashboards. Set interval to get a timeseries per group instead of a single scalar per group - this covers timeseries use cases without needing a separate tool.

Use this when:

• "Group errors by service"

• "Top 10 services by request count"

• "Average duration per endpoint, per hour" (set interval="1h")

Query and visualize time series metrics.

Use this when: need to check system performance, resource usage, or custom metrics.

Common queries:

• CPU: "avg:system.cpu.user{*}"

• Memory: "avg:system.mem.used{*}"

• By host: "avg:system.load.1{host:web-01}"

• By tag: "sum:requests.count{env:prod}"

List all metrics available in Datadog.

Use this when: don't know the exact metric name, or want to discover what's available. For metric metadata (description, unit, type) and tags on a specific metric, use describe_metric instead.

Send custom metric data points to Datadog.

Use this when: need to track custom application metrics or business KPIs.

Metric types:

• gauge: Point-in-time value (temperature, queue size)

• count: Count of events in interval

• rate: Events per second

List metrics that have reported data since a given time.

Use this when: you want to know what's actually emitting data recently, as opposed to list_available_metrics which lists every metric name Datadog knows about (including ones that stopped reporting long ago).

Get metadata (description, unit, type) and known tags for a metric.

Use this when: you need to understand what a metric means or what tags you can group/filter by before writing a query_metrics or monitor query. Consolidates metric metadata and tag discovery into a single call.

Search distributed traces and spans for performance analysis (paginated).

Use this when: debugging slow requests, finding errors in services, or analyzing latency. For statistics (latency percentiles, error rates) without fetching raw spans, use aggregate_spans instead - it is much lighter for dashboards/analytics.

Common queries:

• Find errors: "service:api @error.message:*"

• By status: "service:checkout @http.status_code:500"

• Custom tags: "@airline_name:aeromexico @session_id:*"

Get complete trace with all spans and timing information.

Use this when: need to see full request flow across services (after finding a trace ID).

List services sending APM data in the last hour.

Use this when: want to see what services are instrumented or find service names.

Aggregate spans by a field for latency/error statistics (no raw span data transfer).

PERFECT for "what's slow" or "what's erroring" questions without paying the cost of fetching and reading raw spans with search_apm_traces.

Use this when:

• "p95 latency by service"

• "Error count by endpoint"

• "Average duration per operation"

Browse all Datadog dashboards.

Use this when: want to see what dashboards exist or find a specific dashboard.

Get complete dashboard configuration and widgets.

Use this when: need to see what's in a dashboard or copy its configuration. Large dashboards may have their widget list truncated (see the truncated/ warning/total_available fields) to stay within the response size budget.

Create a new dashboard with custom widgets and layout.

Use this when: user wants to visualize metrics, create a monitoring view, or track KPIs. See the datadog://widget-templates resource for ready-to-use widget definitions for the most common widget types (timeseries, query_value, toplist).

Layout types:

• "ordered": Timeline view (widgets stacked vertically)

• "free": Free-form placement (drag anywhere)

Modify an existing dashboard. Overwrites the given fields; anything omitted is unchanged.

Use this when: need to add widgets, change layout, or update dashboard config. There is no undo tool for dashboard updates - the previous widget/config state is not recoverable through this server once overwritten.

Browse all monitors and their current alert states.

Use this when: want to see what's being monitored or check alert status. For a faceted/full-text search instead of exact filters, use search_monitors.

Get complete monitor configuration and current status.

Use this when: need to see monitor details, thresholds, or notification settings.

Create a new monitor to alert on metrics, logs, or APM data.

Use this when: user wants to get notified about issues, set up alerting, or monitor SLAs. Consider validate_monitor first to check the query syntax before creating.

Query examples:

• Metric: "avg(last_5m):avg:system.cpu.user{*} > 80"

• Log: 'logs("status:error").index("*").rollup("count").last("5m") > 100'

• APM: "avg(last_10m):trace.web.request{service:api}.errors.rate > 5"

Modify an existing monitor's configuration. Overwrites given fields; rest is unchanged.

Use this when: need to adjust thresholds, change notifications, or update alert logic. There is no undo tool - the previous configuration is not recoverable once overwritten.

Temporarily mute/silence monitor notifications.

Use this when: performing maintenance, testing, or a known issue doesn't need alerts right now, for a single monitor. For muting many monitors on a schedule by scope (e.g. "all monitors in this env, this weekend"), use schedule_downtime instead - it is Datadog's purpose-built tool for scheduled, scoped silencing.

Resume notifications from a muted monitor.

Use this when: maintenance is complete or ready to receive alerts again.

Full-text/faceted search across monitors (e.g. by tag, status, or text in the query/name).

Use this when: list_all_monitors's exact-match filters aren't enough - e.g. searching monitor names/queries by substring across facets at once.

Validate a monitor query's syntax without creating anything.

Use this when: want to check a monitor definition is well-formed before calling create_alert_monitor, especially for hand-built queries. This never creates, modifies, or persists a monitor - it is a pure syntax/semantics check.

Note: validating a "log alert" monitor may additionally require the app key to have log data read access without further scoping; if that's missing you will see a permission error here specifically for log-type queries even though other monitor types validate fine.

Browse scheduled/active downtimes (scoped monitor mutes).

Use this when: want to see what's currently muted org-wide, or audit upcoming maintenance windows.

Get complete details of a specific downtime.

Use this when: need to see a downtime's exact scope, schedule, or status.

Schedule a downtime to mute a scope of monitors (or one monitor) over a time window.

Use this when: silencing many monitors at once by scope/tag (e.g. "mute all alerts for env:staging this weekend"), or muting on a schedule with a known end time. For muting exactly one already-known monitor with no scheduling needs, silence_monitor is simpler. At most one of monitor_id/monitor_tags should be set; if neither is set, the downtime applies to all monitors matching scope.

Modify an existing downtime's scope, schedule, or message.

Use this when: need to extend/shorten a downtime's window, change its scope, or end it early (set end to "now"). There is no undo tool - the previous downtime configuration is not recoverable once overwritten.