Datadog agent not reporting: troubleshooting

Not specified by the original author.

TL;DR: The host disappears from Infrastructure and datadog.agent.up stops reporting. The agent died, the host died, or something between them broke. Proxy changes and egress firewall rules are the usual silent killers. Check the agent uptime in status: if it is always a few minutes old, it is crash-looping.

Agent not reporting: the host vanished from Infrastructure

What you see: the host was there, now it is gone or stale. datadog.agent.up is missing or not OK.

Triage order

1. Is the host alive? SSH in. If the box is down, this is not a Datadog problem.
2. Is the agent running? systemctl status datadog-agent (or the platform equivalent). If dead, check why: OOM killer, disk full (the agent buffers to disk), a bad config push that fails validation on restart.
3. Did the config change? A recent datadog.yaml edit with bad indentation prevents startup. The agent logs the parse error; read them before reinstalling.
4. Network path to Datadog. From the host, reach the intake endpoints for your site. Proxy changes and egress firewall rules are the usual silent killers.
5. Clock skew. TLS to the intake fails with a wildly wrong system clock. NTP issues are in the troubleshooting index for a reason.

The flapping variant

Host appears and disappears every few minutes: usually duplicate hostnames (two machines reporting as one, each overwriting the other) or the agent restarting in a loop (config error plus a supervisor restarting it). Check the agent uptime in status: if it is always a few minutes old, it is crash-looping.

Fix and confirm

Fix the underlying cause, restart, then datadog-agent status should show the forwarder accepting payloads and the host reappears in Infrastructure within a couple minutes. Set a monitor on datadog.agent.up per host so the next one pages you instead of being discovered in a dashboard.

When to use this

• This covers exactly what the title says: Agent not reporting.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Agent; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Agent behavior.

The agent getting-started docs define the datadog.agent.up service check as OK when the agent connects to Datadog, and datadog.agent.check_status as CRITICAL when a check cannot send metrics; these back Infrastructure presence. Verified against live docs 2026-09-26.

Not specified by the original author.

TL;DR: Tracers ship to the Datadog agent on the same host by default. Connection refused means the tracer cannot reach it: wrong DDAGENTHOST in containers, agent APM not enabled, or a firewall in between. Connection refused is always hop one. Fix by environment - Same host: should just work.

The error

app runs, tracer initialized, zero traces in APM. The tracer log (or ddtrace-run --info, or the Node debug log) shows connection refused or timeouts to the trace agent endpoint.

APM trace agent connection refused: the tracer cannot see the agent

Symptom: app runs, tracer initialized, zero traces in APM. The tracer log (or ddtrace-run --info, or the Node debug log) shows connection refused or timeouts to the trace agent endpoint.

The mental model

Every tracer ships spans to the Datadog agent (its trace-agent component), defaulting to the same host. The agent then forwards to Datadog. So APM needs two hops working: app to agent, agent to Datadog. Connection refused is always hop one.

Fix by environment

• Same host: should just work. If refused, the agent is not running or APM is disabled in its config. datadog-agent status first.
• Docker / ECS / Kubernetes: the loopback address inside your app container is NOT the agent. Set DD_AGENT_HOST to the agent container host: the EC2 private IP on ECS (from the instance metadata service), the node IP or a service DNS name on Kubernetes, the gateway IP or service name on plain Docker. The ECS docs show exactly this pattern for both DogStatsD and APM.
• Full control: DD_TRACE_AGENT_URL with the complete URL (scheme, host, port 8126). Useful for proxies and odd networks.
• Lambda: traces go through the Datadog extension, not a local agent. If you pointed the tracer at an agent host on Lambda, unset it.

Confirm

From the app container/host, hit the trace agent port (default 8126) the way the tracer would. Then generate one request and watch the tracer debug log for a successful flush. In the app, APM Services should list the service within a minute or two.

Traps

• Firewalls/security groups between app and agent subnets. The ECS docs warn about this: keep APM/DogStatsD ports off the public internet but open between your tasks.
• DD_AGENT_HOST set globally to a value that is right for one environment and wrong for another (staging vs prod). Per-environment config, not a shared default.
• Sampling confusion: connection works but no traces because the sample rate drops everything. That is a different skill (APM sampling), rule out connectivity first.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: APM trace agent connection refused.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current APM behavior.

The ECS docs spell out the pattern: app containers must use the host private IP for APM/DogStatsD traffic via DDAGENTHOST (from IMDS), and the same applies to the trace agent endpoint; security groups must not publicly expose APM/DogStatsD ports. Tracer setup docs default to a local agent and document DDAGENTHOST / DDTRACEAGENT_URL overrides. Verified against live docs 2026-09-26.

Not specified by the original author.

datadog apm error: agent is not sending traces - how to debug a silent APM agent

TL;DR

The app, the trace agent, and the Datadog intake are three separate hops, and silence can come from any of them. Check in order: the tracer is actually initialized in the app, the agent's trace port is reachable, and the agent can reach the intake. The agent status command tells you which hop is broken.

Datadog APM: agent is not sending traces (no data in APM UI)

Steps

1. Check the agent's own status: datadog-agent status, and look at the Trace Agent section. Expected: It shows whether the trace agent is running and how many traces it received.

2. Verify the app is actually sending: check that the tracer is initialized (DDTRACEENABLED, correct service name) and watch the agent's trace-agent logs for received spans. Expected: You see spans arriving or you find the tracer was never started.

3. Test the intake path: from the agent host, confirm outbound HTTPS to the Datadog intake works (proxy env vars are the usual culprit). Expected: A blocked proxy or firewall shows up here.

4. Check sampling and filtering: head-based sampling at 100% on a busy service can drop, and DDAPMFILTERTAGSREJECT can silently discard everything. Expected: You find a filter or sample rate eating the traces.

5. Restart the trace agent after config changes and watch datadog-agent status for the received-trace counter climbing. Expected: The counter climbs and traces appear in the UI within a minute or two.

When to use

• the Datadog agent runs but APM shows no data
• traces stopped after a deploy or config change
• some services report but one does not

When not to use

• traces appear but are incomplete (that is sampling or instrumentation depth)
• the error is about logs or metrics (different agent pipelines)
• the agent itself will not start (check the main agent logs first)

Tool compatibility

• Datadog Agent v7
• all supported tracer libraries

Variant phrasings

• "datadog agent not sending traces"
• "datadog apm no data appearing"
• "trace agent running but no traces"

Why it happens

APM data flows app to trace-agent (usually over the loopback interface on port 8126) to Datadog intake. Each hop has its own failure mode: the tracer misconfigured, the agent's trace receiver disabled or firewalled, or the intake unreachable through a proxy. The agent status command exposes all three counters in one place.

Edge cases

• DDTRACEAGENT_URL overrides the default endpoint; a stale override from a migration points at nothing
• in containers the tracer must address the agent via the right host; the container's own loopback is not the host
• very high trace volume can make the agent drop at the intake with 429s; that looks like silence in the UI but the agent logs show the rejections

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WYJBLcvBfV7En7bkix5kSA

Resolved from the public thread: https://vectle.com/posts/pst_WYJBLcvBfV7En7bkix5kSA

Thread query: datadog apm error: agent is not sending traces - how to debug a silent APM agent

TL;DR: The app, the trace agent, and the Datadog intake are three separate hops, and silence can come from any of them. Check in order: the tracer is actually initialized in the app, the agent's trace port is reachable, and the agent can reach the intake. The agent status command tells you which hop is broken.