Datadog Support
Last reviewed by Scott Sternloff
Datadog runs the platform. What most teams actually need help with is operating it: the custom metric cardinality that doubled the bill, agents that stopped reporting after a Kubernetes upgrade, traces that never link to their logs, and monitors that page eight people at 3am for something nobody acts on. AceMQ engineers work at that layer, on a 15-minute emergency SLA.
Support quotes answered within 1 hour, by a senior engineer.
Planning a build, upgrade or migration instead? See AceMQ Datadog consulting and services.
Customers
Partners
Incident Triage
These are real symptoms from real Datadog production environments — and the first thing our engineers check when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| Bill jumped 40% this month with no infrastructure change | The custom metrics usage page, sorted by metric name. A team almost certainly added a tag carrying a user ID, request ID, or pod name — custom metrics bill per unique tag combination, so one tag on one metric can create hundreds of thousands of billable series overnight. | Under 2 hours |
| Agent healthy but a container's integration reports nothing | The agent status output for autodiscovery, then the pod annotations. Container checks are configured by annotation or label, so a renamed container in the pod spec silently detaches the check while the agent itself stays perfectly green. | 1–2 hours |
| Log costs high while the logs you want are not searchable | Ingestion volume against indexed volume, then your exclusion filters. Ingest and index are billed separately, so it is entirely possible to pay to ingest terabytes of debug logs while the errors you actually query fall outside a retention filter. | 1–3 hours |
| APM traces exist but do not link to the corresponding logs | Whether trace_id and span_id are being injected into the log records. Correlation depends on those fields reaching the log pipeline in the format the remapper expects — custom JSON loggers and structured logging wrappers commonly drop them. | 1–2 hours |
| The trace for the incident you are investigating is missing | The sampling configuration. Head-based sampling decides at the entry span, so low-rate errors are exactly what gets discarded. Error and rare-trace retention filters plus targeted trace sampling on the affected service fix this properly. | 1–3 hours |
| Monitors paging repeatedly for conditions nobody acts on | Which monitors fired most over the last quarter and how many produced a real action. Alert fatigue is nearly always a handful of monitors with no evaluation window, no recovery threshold, and no downtime scheduled around known deploy windows. | Same day |
| Agent DaemonSet running but cluster-level metrics missing | Cluster Agent RBAC. Kubernetes state metrics come from the Cluster Agent talking to the API server, so a ClusterRole that was not updated for a new resource type produces exactly this — node metrics fine, cluster metrics absent. | 1–2 hours |
| Terraform plan wants to recreate monitors somebody edited in the UI | Which monitors have drifted and who owns them. Datadog resources managed in Terraform but edited in the console produce permanent diffs, and applying blindly reverts thresholds that an on-call engineer deliberately changed at 4am. | Under 2 hours |
Resolution times reflect typical Datadog engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.
What's Included
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
Custom metric attribution by team and service, tag cardinality reduction, log ingest versus index tuning, and APM host and span commitment sizing. We find what is driving the bill and cut it without losing the signal you rely on.
Agents dark across a cluster, monitors silent, or telemetry missing during a live incident. A senior engineer joins a bridge within 15 minutes — losing observability mid-incident extends every other outage you are having.
DaemonSet and Cluster Agent deployment, autodiscovery annotations, Cluster Role and RBAC, admission controller injection, and the upgrade paths that quietly change how checks are configured.
Tracer instrumentation, service and env tagging discipline, trace_id injection into logs, sampling and retention filters, and making sure the trace you need during an incident is one that was actually kept.
Pruning monitors that never led to action, setting evaluation windows and recovery thresholds against real noise, scheduling downtime around deploys and maintenance, and routing so one failure pages one team once.
Consolidating from several tools into Datadog, or moving workloads to Prometheus and Grafana where the economics stop working. We run both stacks in production and will tell you honestly which one your case calls for.
Why AceMQ
Nobody selling you the platform has that incentive. Cardinality attribution, log index tuning, and sampling design regularly take six figures off an annual spend — and the savings are permanent because we fix the instrumentation, not just the filters.
The same senior engineers stay on your account. They know your tag taxonomy, your monitor structure, and which services are instrumented properly — so a P1 opens with diagnosis instead of orientation.
You reach a senior engineer directly by phone, email, or Slack. Nobody collects details to pass along, and there is no escalation approval standing between you and the person who can fix it.
Datadog owns the platform and supports it well. Your agents, your tags, your instrumentation, your monitor design, and your bill sit on your side of that line. That is the side we work on, alongside vendor support rather than instead of it.
We also run Prometheus and Grafana in production. When Datadog is the right answer we make it work properly; when a high-volume workload would be cheaper self-hosted, we say so and can move it.
Engineers across 26+ countries and every time zone. Your 3am incident is someone's mid-afternoon — no overnight skeleton crew, no waiting for a region to come online.
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
Escalation Path
Every tier reaches a senior Datadog engineer. There is no tier-1 triage layer to get through.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Pricing
AceMQ Datadog support contracts typically run $24,000–72,000 a year, depending on SLA level, scope (number of clusters or nodes, and environments) and deployment (self-managed, cloud-managed or Kubernetes).
| What moves the price | How it changes the contract |
|---|---|
| SLA level | Business-hours cover costs less than 24/7 cover with a 15-minute emergency response. |
| Scope | More clusters or nodes, and more environments, make a larger contract. |
| Deployment | Self-managed, cloud-managed and Kubernetes estates need different amounts of hands-on work. |
Covering several technologies under one contract, for example RabbitMQ, Kafka and Redis, earns an aggressive discount.
Support In Practice
Datadog support work from AceMQ. Each card links to the full write-up: the estate and its agents, what AceMQ diagnosed or changed, and the result.
Global Logistics Provider
Remediation of intermittent Datadog telemetry gaps traced to agent buffering, container lifecycle, and network egress behavior on the customer's own infrastructure.
Datadog
Kubernetes
Linux
OpenTelemetryB2B SaaS Platform Provider
Ongoing support for a Datadog monitor estate producing more alerts than the on-call rotation could meaningfully act on.
DatadogKubernetes
TerraformPagerDutyGlobal Payments Processor
Assessment of APM instrumentation coverage and trace completeness across a service estate where distributed traces kept breaking at service boundaries.
DatadogOpenTelemetryKubernetes
Java
PythonDigital Commerce Platform
Consulting engagement to govern custom metric cardinality, log ingest, and trace volume so observability spend tracks value instead of accident.
DatadogKubernetesTerraformOpenTelemetrySupport options
AceMQ offers Datadog support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for agents and monitors your team runs, proactive monitoring that catches cardinality and monitor-noise problems first, managed Datadog operations inside your own account, and fully managed Datadog run on your behalf from AceMQ-managed accounts and infrastructure, with the agents and pipelines. Datadog itself stays Datadog's SaaS.
You run it, we back you up
Best for: Platform teams that run their own Datadog estate and need senior cover when telemetry goes dark.
You run it, we watch it with you
Best for: Teams that want the cardinality spike found before the invoice, not after it.
We run it in your cloud or data centre
Best for: Regulated estates that need Datadog operated inside their own accounts and change process.
We host it and run it, as a service
Best for: Teams that want the collection tier run for them while their engineers keep building monitors and dashboards.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs Datadog day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for Datadog
Support is one part of what AceMQ does for Datadog. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
Datadog supports their platform, and they are good at it. They do not tune your tag cardinality, redesign your monitors, fix the tracer instrumentation in your services, or tell you which team's metrics are driving the bill — because those live in your code and your account, not in their platform. That is the work we do, on a 15-minute emergency SLA, alongside your Datadog support rather than replacing it.
Start with attribution, because most teams cannot say which services or teams are driving spend. We break usage down by custom metric, log index, APM host, and span volume, then find the specific tags creating cardinality — usually one or two metrics carrying an unbounded dimension like user ID or pod name. From there it is exclusion filters, log index retention tuning, sampling configuration, and instrumentation fixes so the growth does not simply return next quarter.
Custom metrics are billed per unique combination of metric name and tag values, so the trigger is usually a code change rather than an infrastructure one. Someone adds a tag for user ID, request path, or container ID to an existing metric, and a metric with 200 series becomes one with 200,000. The same pattern happens with log ingestion when a service ships to debug level. We identify the exact change, cap it, and add guardrails so the next one is caught before the invoice.
P1 emergencies — agents dark across a cluster, monitors silent, telemetry missing during a live incident — get a 15-minute first response with a senior engineer on a bridge. P2 critical issues are 1 hour, P3 high-priority 4 hours, and P4 standard questions next business day. These are contractual response times. We treat blind observability as P1 because it makes every concurrent incident harder to resolve.
Yes, and it is a routine one. Kubernetes upgrades commonly break the Cluster Agent's RBAC when a resource type moves API version, change how the admission controller injects tracer libraries, or invalidate autodiscovery annotations after a container rename in the pod spec. The agent itself usually reports healthy throughout, which is why these take a while to notice. We diagnose against agent status output and the actual pod spec rather than the Helm values file.
Sometimes, and we will give you an honest answer because we run both in production. Datadog's value is real — correlated APM, logs, and infrastructure in one place with almost no operational overhead. That value stops scaling when a small number of very high-volume workloads dominate the bill, and those specific workloads are often much cheaper self-hosted. A hybrid split is frequently the right outcome rather than an all-or-nothing migration.
Yes. When a fault sits inside Datadog's product, a case with the right evidence gets resolved faster. We run the agent flare command with your case ID so the agent's logs and configuration attach to the ticket, add reproduction steps and a timeline, and stay on the case until it closes. Most issues never need Datadog support at all, because the cause is in tagging, agent configuration or the environment around it, which we fix directly.
Yes. Datadog accepts OpenTelemetry data two ways: OTLP ingestion in the Datadog Agent, or the OpenTelemetry Collector with the Datadog exporter. Both work; the problems are in the mapping. Resource attributes have to land as the service, env and version tags Datadog uses to link traces, logs and metrics, and high-cardinality attributes become billable custom metric tags. We set up the pipeline, attribute mapping and sampling so correlation works and the bill stays predictable.
Yes. AceMQ works on Datadog in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your Datadog environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Datadog is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
Reactive cover, proactive reviews, or AceMQ running Datadog for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
Production incident right now?Email a Datadog Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
