Your team is halfway through a deploy when a service alert fires, and the runbook says: “Grab the API key from 1Password.” You open a vault, copy a token, paste it into a terminal, and now your shoulder’s tense. Did you rotate that key last quarter? Did everyone else on the team? This is where 1Password and Datadog need to talk directly.
1Password is great at managing secrets, not at graphing system drift. Datadog excels at surfacing infrastructure health, not at storing credentials. When you connect them, you get watchful observability that also respects least privilege. No more sticky notes, no sprawling environment variables, just a clean loop between visibility and security.
At the simplest level, the 1Password Datadog integration lets Datadog agents or monitors fetch monitored credentials without exposing them to humans. Instead of embedding static tokens, Datadog queries secrets from 1Password’s Secrets Automation service. That means short-lived access, automatic rotation, and a full audit trail. The logic is simple: one tool holds secrets, the other uses metrics to verify that those secrets still behave correctly.
A good workflow starts with defining an identity boundary. Tie each Datadog API key or service check to a 1Password item mapped to your identity provider, like Okta or Azure AD, through OIDC. Store credentials there, restrict read permissions to the Datadog integration user, and log every fetch. Then configure Datadog to pull from the 1Password Connect API using a service token, not personal credentials. Rotate the service token quarterly. Let your CI pipeline request fresh secrets automatically at build time so nobody ever “knows” the secret at all.
Troubleshooting usually comes down to permission drift. If a fetch fails, confirm that the integration user in 1Password still matches the service identity in Datadog. Reject configs that tempt you to hardcode tokens. Every “temporary” test key eventually becomes production.