Datadog Agent Installed but No Metrics: A Diagnostic Guide

Your host is healthy, the Datadog Agent is installed, and yet dashboards show gaps and "no data" monitors keep firing. This condition almost always comes down to one of four causes: a bad API key, an Agent that is not actually running, blocked outbound connectivity, or a hostname/tag mismatch that makes data look lost when it is merely attributed somewhere unexpected. This guide walks through the checks in order, from the host outward, and ties each fix to a specific finding.

Commands below assume Agent 6 or 7 on Linux. Exact paths and subcommands vary by Agent major version and operating system, so confirm against your installed version before assuming a command exists.

Recognizing the condition

Typical symptoms, while the workload itself is fine:

• The host appears stale or missing in the Infrastructure List.
• Dashboards show gaps or flat "no data" regions for that host.
• "No data" monitor alerts fire for metrics that should exist.
• Other hosts in the same account report normally (or, in the account-wide case, none do).

Cause and diagnostic summary

Step 1: Confirm the Agent is actually running

On the affected host, as a user with permission to query the Agent (typically root or a user in the dd-agent group):

datadog-agent status

Read three sections carefully: the Agent itself, the forwarder, and the collector. The forwarder section shows recent API transactions and the last successful payload timestamps. The collector section lists each check with its last run status and any errors. If the command fails entirely, check the service manager (systemctl status datadog-agent on systemd hosts) to see whether the process is down or crash-looping.

Step 2: Read the logs for the failure signature

Agent logs on Linux live under /var/log/datadog/, primarily agent.log. The error type tells you which layer is broken:

• HTTP 403 responses mean authentication failed: the API key is wrong, revoked, or from a different Datadog site/organization than you expect.
• Connection timeouts or TLS errors mean the host cannot reach Datadog intake endpoints: a firewall, security group, or missing proxy configuration.
• Check-level errors (Python tracebacks, configuration warnings) mean the Agent runs but a specific integration is broken, which explains partial rather than total data loss.

Step 3: Verify configuration and run one check manually

Two commands narrow this down:

datadog-agent configcheck
datadog-agent check <integration_name>

configcheck shows which integration configurations the Agent actually loaded, including file paths and syntax errors. Running a single check manually shows whether it emits metrics locally at all. If the check produces metrics locally but they never appear in the platform, the problem is in the forwarder or network path, not the check.

Step 4: Test outbound connectivity

The Agent sends data over HTTPS on port 443 to Datadog intake endpoints. From the host, test egress (for example with curl -v against your site's intake endpoint). Note that Datadog uses separate endpoints for metrics, logs, APM, and other products; a firewall rule that permits only one produces misleading partial data loss. If a proxy is required, configure it in datadog.yaml and restart the Agent.

Step 5: Rule out hostname and tag mismatches

If the forwarder reports successful submissions, compare the hostname in the datadog-agent status output against the hostname shown in the Infrastructure List. Cloud provider metadata, container environments, and explicit hostname settings can make the Agent report under an unexpected name, so the data exists but is attached to a host you are not looking at. Search Metrics Explorer for the metric across all hosts before concluding data is absent.

Fixes tied to findings

• 403 errors: set the correct API key in datadog.yaml and restart the Agent. Restarting briefly interrupts collection, so plan it during a low-risk window on production hosts. Never paste full API keys into tickets or chat, and rotate any key that may have been exposed.
• Timeouts: open egress to all Datadog intake endpoints in use, or configure the proxy settings, then restart.
• Check errors: fix the integration YAML under conf.d/, re-run configcheck, and restart if needed.
• Hostname mismatch: set an explicit hostname or fix tag configuration so data lands where you expect it.

Verifying the fix

After any change: re-run datadog-agent status and confirm the forwarder shows recent successful API transactions with no persistent errors. Then trigger a manual check run and confirm the metric appears in Metrics Explorer for the expected host and tags within a few minutes.

When to escalate to Datadog support

Escalate when the Agent reports successful payload submission but data still does not appear after verification, or when many hosts fail simultaneously, which points to an account-level or platform-side issue rather than local misconfiguration. Include the output of an Agent flare (datadog-agent flare) rather than hand-copied logs, and redact credentials.