Below is a Datadog Agent command cheat sheet in table format. I’m focusing only on Agent CLI / Agent service commands, with practical examples and explanations. The main official command family is datadog-agent <subcommand> on hosts, while Docker/Kubernetes often use agent <subcommand> inside the Agent container. Datadog’s command reference lists status, configcheck, diagnose, flare, health, hostname, jmx, stream-logs, version, and related service commands as core Agent commands. (Datadog)
1. Command Format by Runtime
| Runtime | Command Pattern | Example | Explanation |
|---|---|---|---|
| Linux host | sudo datadog-agent <command> | sudo datadog-agent status | Standard command style when Agent is installed directly on Linux. |
| Docker Agent container | docker exec -it <container> agent <command> | docker exec -it datadog-agent agent status | Inside the Datadog container, the binary is usually called agent. |
| Kubernetes Agent pod | kubectl exec -it <pod> -- agent <command> | kubectl exec -it datadog-agent-abc12 -n datadog -- agent status | Used when Datadog Agent runs as a DaemonSet pod. |
| macOS | datadog-agent <command> | datadog-agent status | Used on macOS host installations. |
| Windows | agent.exe <command> | & "$env:ProgramFiles\Datadog\Datadog Agent\bin\agent.exe" status | Used from elevated PowerShell or Command Prompt. |
| Cluster Agent | datadog-cluster-agent <command> | kubectl exec -n datadog deploy/datadog-cluster-agent -- datadog-cluster-agent status | Used specifically for Kubernetes Cluster Agent, not node Agent. |
2. Main datadog-agent Commands
| Command | Linux Example | Kubernetes / Docker Example | What It Does | When to Use |
|---|---|---|---|---|
status | sudo datadog-agent status | kubectl exec -it <pod> -n datadog -- agent status | Shows full Agent status, enabled checks, running integrations, logs Agent, APM Agent, process Agent, DogStatsD, hostname, API key status, and recent errors. | First command to run when troubleshooting almost anything. |
health | sudo datadog-agent health | kubectl exec -it <pod> -n datadog -- agent health | Prints Agent component health. | Use when Agent is running but may be partially unhealthy. |
diagnose | sudo datadog-agent diagnose | kubectl exec -it <pod> -n datadog -- agent diagnose | Runs connectivity and configuration diagnostics. | Use for network, API key, site, proxy, or intake issues. |
configcheck | sudo datadog-agent configcheck | kubectl exec -it <pod> -n datadog -- agent configcheck | Shows all loaded and resolved integration configurations. | Use when an integration, autodiscovery config, or YAML config is not being picked up. |
check <check_name> | sudo datadog-agent check postgres | kubectl exec -it <pod> -n datadog -- agent check redisdb | Runs one specific integration check manually and prints result/errors. | Use when PostgreSQL, Redis, NGINX, Kafka, MySQL, etc. metrics are missing. |
hostname | sudo datadog-agent hostname | kubectl exec -it <pod> -n datadog -- agent hostname | Prints the hostname used by the Agent. | Use when host is missing, duplicate hosts appear, or hostname is unexpected. |
flare | sudo datadog-agent flare | kubectl exec -it <pod> -n datadog -- agent flare | Collects Agent logs/config/debug data for Datadog Support. Sensitive values are scrubbed. | Use when escalating to Datadog Support or collecting deep diagnostics. |
stream-logs | sudo datadog-agent stream-logs | kubectl exec -it <pod> -n datadog -- agent stream-logs | Streams logs being processed by a running Agent. | Use when log collection is enabled but logs are missing in Datadog. |
version | datadog-agent version | kubectl exec -it <pod> -n datadog -- agent version | Prints Agent version information. | Use before upgrades, support cases, or feature compatibility checks. |
help | datadog-agent --help or datadog-agent check --help | kubectl exec -it <pod> -n datadog -- agent --help | Shows available commands or help for a subcommand. | Use when checking supported flags/options on your Agent version. |
config | sudo datadog-agent config get log_level | kubectl exec -it <pod> -n datadog -- agent config get log_level | Manages runtime-editable Agent configuration. | Use to view or temporarily change supported runtime settings like log level. |
import | sudo datadog-agent import <old_config_path> | Usually not common in Kubernetes | Imports/converts configuration files from older Agent versions. | Use during migration from older Datadog Agent versions. |
jmx | sudo -u dd-agent datadog-agent jmx list collected | kubectl exec -it <pod> -n datadog -- agent jmx list collected | Troubleshoots JMX-based integrations. | Use for Kafka, Tomcat, Cassandra, Solr, ActiveMQ, JVM apps. |
launch-gui | datadog-agent launch-gui | Not normally used in Kubernetes | Starts Datadog Agent GUI where supported. | Mostly useful on desktop/server installs with GUI support. |
start-service | Windows only | Not applicable | Starts the Agent service through Windows service manager. | Windows host Agent management. |
restart-service | Windows only | Not applicable | Restarts the Agent service through Windows service manager. | Windows host Agent management. |
stopservice | Windows only | Not applicable | Stops the Agent service through Windows service manager. | Windows host Agent management. |
3. Agent Service Start / Stop / Restart Commands
These are not always datadog-agent <subcommand> commands, but they are important Agent operations. Datadog documents start, stop, restart, service status, and Agent information commands separately by platform. (Datadog)
| Task | Platform | Example Command | Explanation |
|---|---|---|---|
| Start Agent | Linux with systemd | sudo systemctl start datadog-agent | Starts the Datadog Agent service. |
| Stop Agent | Linux with systemd | sudo systemctl stop datadog-agent | Stops the Datadog Agent service. |
| Restart Agent | Linux with systemd | sudo systemctl restart datadog-agent | Restarts Agent after config changes. |
| Service status | Linux with systemd | sudo systemctl status datadog-agent | Checks if the Agent service is active, failed, or restarting. |
| View service logs | Linux with systemd | sudo journalctl -u datadog-agent.service -r | Reads Agent service logs in reverse order. Useful when Agent fails to start. |
| Start Agent | Linux service wrapper | sudo service datadog-agent start | Older/non-systemd style start command. |
| Stop Agent | Linux service wrapper | sudo service datadog-agent stop | Older/non-systemd style stop command. |
| Restart Agent | Linux service wrapper | sudo service datadog-agent restart | Older/non-systemd style restart command. |
| Service status | Linux service wrapper | sudo service datadog-agent status | Checks Agent status using service wrapper. |
| Stop Agent container | Docker | docker exec -it datadog-agent agent stop | Stops the Agent process inside the container. |
| Restart Agent pod | Kubernetes | kubectl delete pod <agent-pod> -n datadog | Deletes pod; DaemonSet recreates it automatically. |
| Start Agent | macOS | launchctl start com.datadoghq.agent | Starts Agent on macOS. |
| Stop Agent | macOS | launchctl stop com.datadoghq.agent | Stops Agent on macOS. |
| Check service | macOS | launchctl list com.datadoghq.agent | Shows macOS Agent service status. |
| Start Agent | AIX | startsrc -s datadog-agent | Starts Agent on AIX. |
| Stop Agent | AIX | stopsrc -s datadog-agent | Stops Agent on AIX. |
| Status | AIX | lssrc -s datadog-agent | Checks Agent service status on AIX. |
4. Runtime Config Commands
Datadog supports runtime configuration commands for certain settings. One common example is changing the Agent log level temporarily, especially in containers where editing config files is inconvenient. Datadog notes this runtime log-level change is available for Agent v6.19+ / v7.19+, but trace-agent container log level still requires redeployment/config change. (Datadog)
| Command | Example | Explanation | When to Use |
|---|---|---|---|
config list-runtime | sudo datadog-agent config list-runtime | Lists runtime-editable settings. | Use to see what can be changed without editing datadog.yaml. |
config get <setting> | sudo datadog-agent config get log_level | Shows current runtime value of a setting. | Use to confirm current log level. |
config set <setting> <value> | sudo datadog-agent config set log_level debug | Sets a runtime-editable value. | Use temporarily while debugging. |
config set log_level info | sudo datadog-agent config set log_level info | Changes log level back to normal. | Use after troubleshooting to avoid noisy logs. |
| Kubernetes runtime config | kubectl exec <pod> -n datadog -- agent config set log_level debug | Sets log level inside running Agent pod. | Useful for temporary Kubernetes troubleshooting. |
| Docker runtime config | docker exec datadog-agent agent config set log_level debug | Sets log level inside container Agent. | Useful for container Agent debugging. |
5. Integration Management Commands
The datadog-agent integration command is available for Agent v6.8+ and manages official Datadog integration Python packages. Datadog documents four main subcommands: install, remove, show, and freeze. Starting with Agent 7.69, Datadog says Community, Partner, and Marketplace integrations are automatically retained during upgrades unless an opt-out file is created. (Datadog)
| Command | Example | Explanation | When to Use |
|---|---|---|---|
integration --help | datadog-agent integration --help | Shows integration command help. | Use to check syntax on your Agent version. |
integration show | sudo -u dd-agent -- datadog-agent integration show datadog-vsphere | Shows installed version/details of an integration package. | Use before upgrading or troubleshooting integration version. |
integration install | sudo -u dd-agent -- datadog-agent integration install datadog-vsphere==3.6.0 | Installs or upgrades a specific integration package version if compatible with the Agent. | Use when you need a newer integration bugfix/feature before full Agent upgrade. |
integration remove | sudo -u dd-agent -- datadog-agent integration remove datadog-vsphere | Removes an integration package. It does not remove its config folder from conf.d. | Use when removing a manually installed integration package. |
integration freeze | sudo -u dd-agent -- datadog-agent integration freeze | Lists Python packages installed in the Agent Python environment. | Use for troubleshooting dependency/version issues. |
| Windows show | & "$env:ProgramFiles\Datadog\Datadog Agent\bin\agent.exe" integration show datadog-vsphere | Windows equivalent. | Use on Windows Agent. |
| Windows install | & "$env:ProgramFiles\Datadog\Datadog Agent\bin\agent.exe" integration install datadog-vsphere==3.6.0 | Installs integration on Windows. | Run PowerShell as Administrator. |
| Windows freeze | & "$env:ProgramFiles\Datadog\Datadog Agent\bin\agent.exe" integration freeze | Lists Agent Python packages on Windows. | Useful for support/troubleshooting. |
Important note: after installing or upgrading an integration with datadog-agent integration install, restart the Agent so the new integration version is used. (Datadog)
6. JMX Troubleshooting Commands
Use these for Java/JMX integrations such as Kafka, Tomcat, Cassandra, Solr, ActiveMQ, JVM apps, and similar. Datadog documents jmx list matching, limited, collected, not-matching, everything, and collect. (Datadog)
| Command | Example | Explanation | When to Use |
|---|---|---|---|
jmx list collected | sudo -u dd-agent datadog-agent jmx list collected | Lists attributes actually collected by the current JMX config. | Use when JMX integration works but expected metrics are missing. |
jmx list matching | sudo -u dd-agent datadog-agent jmx list matching | Lists attributes matching at least one configured JMX instance. | Use to confirm your include rules match MBeans. |
jmx list not-matching | sudo -u dd-agent datadog-agent jmx list not-matching | Lists attributes that do not match any current config. | Use when your bean/filter pattern is wrong. |
jmx list limited | sudo -u dd-agent datadog-agent jmx list limited | Lists attributes that match config but are not collected because of metric limit. | Use when JMX metric limit is reached. |
jmx list everything | sudo -u dd-agent datadog-agent jmx list everything | Lists every available supported JMX attribute. | Use for discovery when building a new JMX config. |
jmx collect | sudo -u dd-agent datadog-agent jmx collect | Starts metric collection using current config and prints metrics to console. | Use to validate JMX metrics before checking Datadog UI. |
| Limit to one check | sudo -u dd-agent datadog-agent jmx list collected --checks tomcat | Runs JMX command only for selected check. | Use when many JMX checks exist on the same Agent. |
| Debug JMX output | sudo -u dd-agent datadog-agent jmx list everything -l debug --flare | Writes debug JMX output under Agent logs so it can be included in a flare. | Use for deep Datadog Support troubleshooting. |
7. Log Troubleshooting Commands
| Command | Example | Explanation | When to Use |
|---|---|---|---|
stream-logs | sudo datadog-agent stream-logs | Streams logs currently being processed by the Agent. | Use when logs exist locally but are not visible in Datadog. |
| Kubernetes stream logs | kubectl exec -it <agent-pod> -n datadog -- agent stream-logs | Streams logs from Kubernetes Agent pod. | Use for container log collection troubleshooting. |
| Agent status for logs | sudo datadog-agent status | Shows Logs Agent section and log sources. | Use to confirm log collection is enabled and sources are active. |
| Config check for logs | sudo datadog-agent configcheck | Shows loaded log collection configs from conf.d. | Use when custom file logs are not picked up. |
8. Integration Check Commands
| Command | Example | Explanation | When to Use |
|---|---|---|---|
check postgres | sudo datadog-agent check postgres | Runs PostgreSQL integration once and prints result. | PostgreSQL metrics missing or DB auth issue. |
check mysql | sudo datadog-agent check mysql | Runs MySQL integration once. | MySQL integration troubleshooting. |
check redisdb | sudo datadog-agent check redisdb | Runs Redis integration once. | Redis metrics missing. |
check nginx | sudo datadog-agent check nginx | Runs NGINX integration once. | NGINX status endpoint/auth/path issue. |
check http_check | sudo datadog-agent check http_check | Runs HTTP check manually. | Endpoint check is not reporting. |
check kubelet | kubectl exec -it <agent-pod> -n datadog -- agent check kubelet | Runs kubelet check from Kubernetes Agent pod. | Kubernetes node/container metrics missing. |
check docker | docker exec -it datadog-agent agent check docker | Runs Docker check inside Agent container. | Docker/container metrics issue. |
9. Cluster Agent Commands
These are technically datadog-cluster-agent commands, not datadog-agent, but they are important in Kubernetes Datadog troubleshooting.
| Command | Example | Explanation | When to Use |
|---|---|---|---|
| Cluster Agent status | kubectl exec -n datadog deploy/datadog-cluster-agent -- datadog-cluster-agent status | Shows Cluster Agent status. | Use when Kubernetes metadata, cluster checks, external metrics, or orchestrator data are missing. |
| Cluster Agent logs | kubectl logs -n datadog deploy/datadog-cluster-agent | Reads Cluster Agent logs. | Use for RBAC, API server, cluster check, and metadata issues. |
| Check deployment | kubectl get deploy -n datadog | Confirms Cluster Agent deployment exists. | Use to confirm Cluster Agent is installed. |
| Describe pod | kubectl describe pod <cluster-agent-pod> -n datadog | Shows events, env vars, mounted secrets, and failures. | Use for CrashLoopBackOff, RBAC, token, or config issues. |
Best Practical Order During Troubleshooting
| Step | Command | Purpose |
|---|---|---|
| 1 | sudo datadog-agent status | Check overall Agent health and enabled components. |
| 2 | sudo datadog-agent health | Confirm Agent internal components are healthy. |
| 3 | sudo datadog-agent diagnose | Check connectivity/config/API/site problems. |
| 4 | sudo datadog-agent configcheck | Confirm loaded configuration. |
| 5 | sudo datadog-agent check <integration> | Debug one integration directly. |
| 6 | sudo datadog-agent hostname | Verify hostname/tagging identity. |
| 7 | sudo datadog-agent stream-logs | Debug log collection. |
| 8 | sudo -u dd-agent datadog-agent jmx list collected | Debug JMX metrics. |
| 9 | sudo datadog-agent flare | Collect support bundle if issue is still unresolved. |
This is the command set I’d expect a strong DevOps/SRE candidate to know for Datadog Agent troubleshooting.
I’m a DevOps/SRE/DevSecOps/Cloud Expert passionate about sharing knowledge and experiences. I have worked at Cotocus. I share tech blog at DevOps School, travel stories at Holiday Landmark, stock market tips at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow , and SEO strategies at Wizbrand.
Do you want to learn Quantum Computing?
Please find my social handles as below;
Rajesh Kumar Personal Website
Rajesh Kumar at YOUTUBE
Rajesh Kumar at INSTAGRAM
Rajesh Kumar at X
Rajesh Kumar at FACEBOOK
Rajesh Kumar at LINKEDIN
Rajesh Kumar at WIZBRAND
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals
The article provides a reference list of
datadog-agentcommands, but it would be even more useful to discuss how these commands fit into day-to-day operations. In production environments, commands such asconfigcheck,diagnose,health, andflareare often integrated into troubleshooting runbooks and automated health checks to reduce MTTR. Another worthwhile addition would be guidance on validating agent configurations during CI/CD deployments, managing version upgrades across large fleets, and detecting configuration drift to ensure consistent observability coverage as infrastructure evolves.