--- title: "Datadog Integration" description: "Operate Datadog from your workflows: agents post events, submit and query metrics, ship and search logs, manage monitors and downtimes, declare incidents, and work with dashboards, SLOs, hosts, users, Synthetics, and notebooks across all Datadog sites." url: https://flowrunner.ai/integrations/datadog date_modified: 2026-08-01T02:40:32-07:00 --- # Datadog [Developer Tools](https://flowrunner.ai/integrations/category/developer-infrastructure) Operate Datadog from your workflows: agents post events, submit and query metrics, ship and search logs, manage monitors and downtimes, declare incidents, and work with dashboards, SLOs, hosts, users, Synthetics, and notebooks across all Datadog sites. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 58 actions · API key · available [Datadog website](https://datadoghq.com/) · [Platform Documentation](https://docs.datadoghq.com/api/latest/) · Capability data verified 2026-07-21 1. A scheduled sweep runs Search Monitors and finds monitors in alert state 2. Search Logs pulls the error lines correlated with each alerting monitor 3. Query Timeseries confirms the spike is sustained, not a blip 4. Create Incident declares the incident with severity and impact filled in 5. On-call is paged through PagerDuty and the incident channel gets a summary 6. The responder reads the assembled evidence and decides severity and next steps ## What This Integration Enables Datadog tells you what is happening. The open question at 3am is who does the mechanical work of responding, and this connector gives that work to agents. They post deploy markers to the event stream, submit business metrics, ship and search logs, sweep monitors for alert states, declare incidents with the evidence attached, and track SLO error budgets, hosts, Synthetics, dashboards, and notebooks across every Datadog site. The line FlowRunner draws is between evidence and silence. Agents are excellent at gathering the first and should never decide the second alone. Correlating logs with a metric spike is mechanical work. Muting monitors is a judgment about what your team is willing to not know, and that judgment stays with a person through a [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) gate. ### Without FlowRunner **Alert archaeology at 3am**: The responder pieces together logs, metrics, and recent deploys by hand while the pager keeps firing **Silence by guesswork**: Monitors get muted ad hoc during maintenance, and nobody is sure what is still watching production **Incidents declared late**: The formal incident starts after the scramble, so the timeline never captures the first minutes ### With FlowRunner **Evidence arrives assembled**: The responder opens an incident that already contains the correlated logs, the metric trend, and the deploy marker **Silencing on the record**: Every downtime is scoped, approved, and time-boxed before any monitor goes quiet **Incidents declared first**: The incident exists from the first confirmed signal, with the triage attached to it ## Use Case Scenarios ### Triage that arrives assembled A scheduled sweep runs Search Monitors for anything in alert state. For each hit, the agent pulls the monitor definition with Get Monitor, searches the correlated log index with Search Logs, and runs Query Timeseries to confirm the anomaly is sustained. Confirmed signals become a declared incident through Create Incident, the on-call responder is paged through [PagerDuty](https://flowrunner.ai/integrations/pagerduty), and the incident channel in [Slack](https://flowrunner.ai/integrations/slack) gets the title, severity, and evidence links. The responder starts from an assembled case file instead of a raw alert. ### Deploys that leave a trail and gate themselves When a release goes out, the agent calls Post Event to drop a deploy marker on the event stream, so every metric graph afterward carries the context. It then fires Trigger Synthetics CI Tests against the critical user journeys and polls Get Synthetics Test Results. Passing results let the rollout proceed and the agent notes it on the event stream. Failing results stop the pipeline and put the diff, the failing journeys, and the marker in front of the release owner. Paired with [Sentry](https://flowrunner.ai/integrations/sentry), a spike in a production error can send the agent back into Search Logs to pull the backend lines that explain it. ### Maintenance windows without accidental blindness Before a planned database migration, the agent prepares the quiet period. It resolves which monitors the proposed scope actually matches, lists them by name, and presents the set to the on-call lead along with what remains watching production. Only after approval does Create Downtime schedule the window, time-boxed to the maintenance plan. When the work finishes early, Cancel Downtime brings coverage back rather than waiting out the clock. ## Human-in-Loop Highlight Create Downtime and Mute Monitor are the two operations in this connector that make your observability deliberately worse, and a scope pattern that matches more than intended means real incidents page nobody. So the maintenance agent treats silencing as a proposal, not an action. It posts to the on-call lead: "The scope env:prod service:checkout matches 14 monitors, listed below. Muting them for the 2-hour window leaves payment-gateway latency as the only active coverage on checkout. Approve this downtime, or tighten the scope?" The lead approves, tightens, or rejects. Nothing goes quiet until a person has read the list of what stops watching. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 58 actions ### Events 3 - **Post Event** Posts a custom event to the Datadog event stream. Used for deploy markers, config changes, and anything worth correlating with a graph later. - **List Events** Queries the event stream between two timestamps. Used to reconstruct what happened around an anomaly. - **Search Events** Searches events with the full Datadog events query syntax. Used to find prior markers for a service before acting. ### Metrics 5 - **Submit Metric** Submits a data point for a custom metric. Used to push business metrics, like orders processed or exceptions flagged, into the same graphs as infrastructure data. - **Query Timeseries** Queries timeseries data with the full Datadog query syntax, including aggregations and functions. The validation step before any agent treats a spike as real. - **List Metrics** Lists metrics known to the organization. Used for discovery before building queries. - **Get Metric Metadata** Retrieves a metric's type, units, and description. - **Update Metric Metadata** Updates a metric's metadata. Used to keep custom metrics documented as they multiply. ### Logs 2 - **Send Log** Sends a log entry to Datadog Log Management through the HTTP intake. Used to ship workflow and agent activity into the same searchable index as application logs. - **Search Logs** Searches indexed logs with the Datadog log search syntax. The core evidence-gathering step in incident triage. ### Monitors 8 - **Create Monitor** Creates a monitor on a metric, log, event, or other data source. Used to codify a new alert the moment a gap is found. - **List Monitors** Lists monitors with filtering by name, tags, and group states. - **Get Monitor** Retrieves a monitor's full definition and current state. Used to understand what an alert actually watches before responding to it. - **Update Monitor** Updates an existing monitor. Used to tune thresholds from a workflow rather than by hand. - **Delete Monitor** Permanently deletes a monitor. There is no undo, so cleanup workflows gate this on review. - **Mute Monitor** Mutes a monitor entirely or for a scope. The silencing operation this page's human gate covers. - **Unmute Monitor** Unmutes a monitor so it resumes notifying. Used to restore coverage the moment maintenance ends. - **Search Monitors** Searches monitors with the monitor search query syntax. The sweep step that finds everything currently in alert state. ### Downtimes 4 - **Create Downtime** Schedules a downtime that mutes matching monitors for a scope. Gated, because scope patterns can match more than intended. - **List Downtimes** Lists scheduled downtimes, optionally only active ones. Used to audit what is currently silenced. - **Get Downtime** Retrieves a downtime's definition and status. - **Cancel Downtime** Cancels a downtime so monitors resume notifying. Used when maintenance finishes early. ### Incidents 5 - **Create Incident** Declares an incident in Datadog Incident Management. Used to make the incident exist from the first confirmed signal. - **List Incidents** Lists incidents with pagination. Used for review cadences and open-incident sweeps. - **Get Incident** Retrieves an incident's state, severity, impact, and timeline metadata. - **Update Incident** Updates an incident's title, state, severity, or impact. Used to keep the record current as responders learn more. - **Delete Incident** Permanently deletes an incident and its timeline. Rarely used, and never without a person confirming. ### Dashboards 4 - **Create Dashboard** Creates a dashboard from widget JSON. Used to stand up a per-incident or per-launch view programmatically. - **List Dashboards** Lists all dashboards with summary information. - **Get Dashboard** Retrieves a dashboard's full definition. Used to clone or audit existing views. - **Delete Dashboard** Deletes a dashboard. Used in cleanup workflows. ### SLOs 6 - **Create SLO** Creates a service level objective. - **List SLOs** Lists SLOs, filterable by name, tags, or underlying queries. - **Get SLO** Retrieves an SLO's full definition, optionally with configured alerts. - **Update SLO** Updates a service level objective. - **Delete SLO** Permanently deletes an SLO. - **Get SLO History** Retrieves uptime percentage and error budget remaining over a window. Used to put error-budget context into release decisions. ### Hosts 9 - **List Hosts** Lists infrastructure hosts reporting to Datadog, with search filtering. - **Get Host Totals** Returns the count of active and up hosts. Used as a quick fleet health check. - **Mute Host** Mutes all monitors covering a host, optionally until a set time with a note. Another silencing operation that workflows gate. - **Unmute Host** Unmutes a host so its monitors resume notifying. - **List All Host Tags** Returns every host tag mapped to the hosts carrying it. Used for fleet-wide tag audits. - **Get Host Tags** Returns the tags on a specific host. - **Add Host Tags** Adds tags to a host without removing existing ones. Used to sync ownership and environment tags from a source of truth. - **Update Host Tags** Replaces a host's tags for a source with a new set. - **Remove Host Tags** Removes all of a host's tags for a source. Destructive to tag-scoped monitors, so reconciliation workflows flag it for review. ### Users 4 - **List Users** Lists organization users with filtering and pagination. - **Get User** Retrieves a user's details and organization role relationships. - **Create User** Creates a user and, by default, emails them an invitation. Used in onboarding workflows. - **Disable User** Disables a user's access to the organization. Used in offboarding workflows, with the identity system as the source of truth. ### Synthetics 4 - **List Synthetics Tests** Lists all Synthetic tests with their status, locations, and tags. - **Get Synthetics Test** Retrieves a test's full configuration, including steps and assertions. - **Trigger Synthetics CI Tests** Triggers Synthetic tests on demand and returns result IDs to poll. The step that lets a deployment gate itself on real user journeys. - **Get Synthetics Test Results** Retrieves a test's latest results, bounded to a window and filterable by location. ### Service Checks, Notebooks, and Account 4 - **Submit Service Check** Submits a service check status for a host. Used to report the health of workflow-managed services into Datadog. - **List Notebooks** Lists notebooks with search and sorting. - **Get Notebook** Retrieves a notebook's full content and cells. Used to pull runbook context into an incident thread. - **Validate API Key** Checks that the configured API key is valid on the configured site. Used as a connection health check before scheduled sweeps. ## Frequently Asked Questions ### What can FlowRunner do with Datadog? FlowRunner agents can run Post Event, List Events, and Search Events in Datadog, plus 55 more actions. ### Does connecting Datadog to FlowRunner require OAuth? No. Datadog connects to FlowRunner with an API key, no OAuth flow required. ### Can Datadog trigger a FlowRunner workflow automatically? Datadog doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Datadog?** This integration exposes Datadog to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/datadog. Site index: https://flowrunner.ai/llms.txt