Datadog MCP

@datadog show me error rate and p95 latency for the checkout service over the last hour

Based on Datadog metrics for the checkout service in the past hour: Error rate averaged 2.3% with a spike to 4.1% at 14:22 UTC. P95 latency held steady around 340ms until 14:20, then jumped to 890ms during the error spike. Both metrics returned to baseline by 14:35. This pattern suggests a brief downstream dependency issue rather than a code regression.

This example assumes the MCP can query time-series metrics and correlate them. You'll need read access to the relevant Datadog monitors and dashboards. Response quality depends on how your services are tagged and instrumented — inconsistent naming makes cross-service analysis harder.

@datadog create a monitor that alerts #oncall if API gateway 5xx rate exceeds 1% for 5 minutes

Monitor created: 'API Gateway 5xx Rate Alert'. Configured to trigger when sum:trace.http.request.errors{service:api-gateway,http.status_code:5xx}.as_rate() exceeds 0.01 over a 5-minute window. Alert routed to Slack channel #oncall with high priority. Monitor ID: mon-abc123def456. You can adjust thresholds or notification channels in the Datadog UI.

This writes a new monitor to your Datadog account. The MCP needs OAuth scopes for monitor creation. If your team uses PagerDuty or Opsgenie integrations, you may need to configure those separately — the MCP handles Datadog-native notifications only. Always verify the query syntax matches your actual metric names.

@datadog compare database query performance between the last deploy and the previous week, then draft a summary for the retro doc

Comparing database query metrics for the postgres-primary instance: Last 24 hours (post-deploy) vs. prior 7-day average. Query count increased 8% (expected with traffic growth). P50 latency improved 12% (94ms → 83ms), likely due to the new index on user_events. However, P99 latency degraded 18% (420ms → 495ms), concentrated in the analytics queries. Draft summary: 'Deploy improved median query speed but introduced a P99 regression in analytics workloads. Investigate query plan changes for the reports endpoint.'

This synthesis example shows the MCP pairing metric retrieval with AI reasoning to produce a retro-ready narrative. Accuracy depends on correct time-window selection and whether your database metrics are tagged consistently. The MCP won't automatically know which deploy corresponds to which time range — you may need to specify commit SHAs or deploy timestamps.

When Datadog MCP helps teams close the loop after outages

A 6-person engineering team runs a SaaS product with 40+ microservices. After a 2am database timeout incident, they gather in Slack at 10am to write the postmortem. The on-call engineer needs to pull CPU graphs, error rates, and deployment timestamps from Datadog without leaving the thread. The Datadog MCP lets the team query metrics and logs directly in Switchy, so the postmortem draft includes actual data instead of vague recollections. This works when your Datadog account has OAuth2 enabled and your incidents happen often enough (once a month or more) to justify the setup cost. If you're only checking Datadog once a quarter, the manual dashboard visit is faster. For teams doing weekly incident reviews or blameless postmortems, this MCP turns Slack into a first-class observability client.

Using Datadog MCP to answer 'is it us or them' questions

A 3-person support team fields tickets about slow API responses. Half the time, the issue is the customer's network; the other half, it's a backend regression. The support rep needs to check request latency and error counts for a specific customer ID without pinging engineering. The Datadog MCP lets them query metrics by tag (customer, endpoint, region) in a Switchy chat, then paste the result into the Zendesk ticket. This shortcut works when your Datadog tags are clean and your support team knows which metrics to ask for. If your tagging is inconsistent or your support reps aren't technical, they'll still escalate to engineering. For teams where support triages 10+ performance complaints a week, this MCP cuts the median resolution time by a day.

When Datadog MCP surfaces deployment impact during retrospectives

A 5-person product team ships 8-12 features per sprint. In Friday retros, they argue about whether the new checkout flow actually reduced latency or just moved the bottleneck. The PM wants to see before-and-after metrics without scheduling a separate meeting with the platform engineer. The Datadog MCP lets the team pull deployment markers and compare p95 latency across the sprint, right in the retro doc. This is useful when your team deploys multiple times a week and your Datadog dashboards are already organized by feature or service. If you deploy once a month or your metrics aren't tagged by feature, the MCP won't have enough granularity to answer the question. For teams running continuous deployment and data-driven retros, this MCP turns observability into a shared language.