Datadog
Turn incidents and requests into Datadog work items, and keep status in step across your tools.
39 ways to read, 7 ways to write, each write switched on by you.
Quality checks
Built and tested with example responses.
- Ready to connect: doneEvery listed action is built in.
- Built and tested with example responses: doneEach action is built from the provider’s published API and tested against example responses, errors, rate limits and paging.
Connected, approved, proven.
The things teams do most with Datadog, an example flow with a person in the loop, and what Nexra keeps as proof.
Top actions
- Schedule downtime
downtimes.createApproval by rule - Post event
events.createApproval by rule - List catalog entities
catalog_entities.listRead
Example flow
- Datadog · List catalog entities
catalog_entities.listDone - Datadog · Schedule downtime
downtimes.createMaker-checker - Nexra · Record the decision and result in the evidence chainProven
Example workflow. Routine runs go through on their own. Only a change your rules flag, such as one over a limit you set, waits for the right person, who sees the exact change and the rule before it reaches Datadog.
What gets logged
- Whether it ran on its own or who approved it, and under which rule
- A fingerprint of the exact request sent to Datadog
- Datadog's reply: what it created or changed
- One entry in the evidence chain, linked to the one before
Try this in the sandbox
Run the whole flow with test data in your sandbox, then connect your own account when you are ready to go live.
For developers
Technical detail
Read and manage Datadog monitors, events, incidents, downtimes and SLOs; read dashboards, synthetics, teams, service catalogue, hosts, logs, log aggregates and metric queries.
Datadog API docs- Source actions
- 39
- Destination actions
- 7
- Data types
- 26
What you can map
Reads are always available. Writes are off until you switch them on for a connection, and governed writes follow your policies.
catalog entities1
- List catalog entitiesSource
Software Catalog entities (services, datastores, queues, systems, APIs) with owners.
catalog relations1
- List catalog relationsSource
Ownership and dependency relations between software catalog entities (owns, dependsOn, partOf and their inverses).
dashboard lists1
- List dashboard listsSource
Manual dashboard lists with their dashboard counts.
dashboards2
- Get dashboardSource
One dashboard with its tags, template variables and widget summary (widget types and titles).
- List dashboardsSource
Dashboard summaries: title, layout, author, URL and timestamps.
downtimes4
- Schedule downtimeDestinationNot retried automaticallyApproval before production
Schedules a one-time or recurring downtime for one monitor or monitors with given tags.
- Get downtimeSource
One downtime with its schedule and status.
- List downtimesSource
Scheduled, active and past downtimes with their monitor selection and schedule.
- Update downtimeDestinationProvider duplicate protectionApproval before production
Changes the scope, monitor selection, schedule or message of a downtime.
events4
- Post eventDestinationNot retried automaticallyApproval before production
Posts an event (for example a deploy or change record) to the event stream.
- Get eventSource
One event with its full attributes.
- List eventsSource
Events from the Events Explorer matching a search query and time range.
- Search eventsSourceIncremental
Event search with a request body, for long queries and time zone options.
host tags1
- Get host tagsSource
Tags on one host, optionally from a single source.
host totals1
- Get host totalsSource
Number of active and up hosts in the organisation.
hosts1
- List hostsSource
Infrastructure hosts with aliases, apps, tags by source and agent metadata.
incident attachments1
- List incident attachmentsSource
Postmortem and link attachments on an incident.
incident todos1
- List incident todosSource
Remediation todos on an incident with assignees, due dates and completion.
incidents5
- Declare incidentDestinationNot retried automaticallyApproval before production
Declares an incident with severity, state, customer impact and commander.
- Get incidentSource
One incident with fields, impact and commander.
- List incidentsSource
Incidents with severity, state, impact and timing fields.
- Search incidentsSource
Incident search with Datadog's incident query syntax, for example state:active.
- Update incidentDestinationProvider duplicate protectionApproval before production
Updates title, severity, state, impact, timings or commander of an incident.
log aggregates1
- Aggregate logsSource
Counts or measures of indexed logs, grouped by facets, over a bounded time window (logs analytics aggregate).
logs1
- Search logsSource
Indexed log events matching a query within a bounded time window.
metric metadata1
- Get metric metadataSource
Type, unit, description and integration of a metric.
metric timeseries1
- Query timeseries (v2)Source
Timeseries points for a metric query and optional formula, sent in the request body (/api/v2/query/timeseries).
metrics2
- List active metricsSource
Names of metrics that reported since a time, optionally for one host or tag.
- Query metricsSource
Timeseries points for a metric query over a bounded time window.
monitor groups1
- Search monitor groupsSource
Per-group monitor states (for example one row per host or service) with last triggered times.
monitors5
- Create monitorDestinationNot retried automaticallyApproval before production
Creates a monitor with a query, message, tags, priority and options.
- Get monitorSource
One monitor with its options, state and optional matching downtimes.
- List monitorsSource
Monitors with their query, options, tags and overall state.
- Search monitorsSource
Monitor search with Datadog's monitor query syntax, including status filters.
- Update monitorDestinationProvider duplicate protectionApproval before production
Edits a monitor. Omitted fields are unchanged; options are replaced as a whole.
services2
- Get service definitionSource
One service definition by service name.
- List service definitionsSource
Service definitions from the Software Catalog with owner, tier and contacts.
slo corrections1
- List SLO correctionsSource
Status corrections that exclude maintenance windows, deployments or off-hours from SLOs.
slo history1
- Get SLO historySource
SLI value, uptime and remaining error budget for an SLO over a time window.
slos3
- Get SLOSource
One SLO with its thresholds and configured alert IDs.
- List SLOsSource
Service level objectives with targets, timeframes and source monitors or queries.
- Search SLOsSource
SLO search by name, tags and type, with overall status per timeframe.
synthetic results1
- List synthetic test resultsSource
Latest result summaries (pass or fail, location, check time) for an API or browser test.
synthetic tests2
- Get synthetic testSource
One synthetic test's metadata, schedule and monitor ID.
- List synthetic testsSource
API, browser, mobile and network synthetic tests with status, locations and monitor ID.
teams1
- List teamsSource
Datadog teams with handle, description and member and link counts.
Access and limits
- Authentication
- API key and application key
- Plans and access
- All Datadog plans; incidents, the software catalogue and logs require the corresponding products. Application keys inherit the creating user's permissions and can be scoped (monitors_read, monitors_write, monitors_downtime, incident_read, incident_write, events_read, logs_read_data, slos_read, apm_service_catalog_read, metrics_read, timeseries_query, hosts_read, dashboards_read, synthetics_read, teams_read).
- Test environment
- A 14-day free trial organisation works for testing.
- Rate limits
- Per-organisation, per-endpoint limits reported in X-RateLimit-Limit/Remaining/Reset headers; HTTP 429 when exceeded (for example 300 monitor reads per minute, logs search 300 per hour by default).
- Pagination
- Events and logs use page[cursor] with meta.page.after; incidents, downtimes, catalogue entities and SLOs use offsets; monitors and service definitions use page numbers; hosts use start/count.
- Provider events
- Webhooks integration for monitor, incident and event notifications. Flows run on demand, on a schedule, or when a scheduled check finds new or changed records.
Before you build a flow
- The Incidents v2 API is in preview (unstable) at Datadog; its fields can change.
- Incident notification handles are not exposed, so creating or updating an incident does not page anyone through Nexra; monitor messages can still contain @-handles.
- Events are posted with the v1 events endpoint on the API host; the v2 event-management intake host is not used.
- Log search and log aggregation are limited to 30-day windows and metric queries to 31-day windows per call.
- Logs search, log aggregation and metric/timeseries queries are heavily rate-limited per organisation (logs queries default to 300 per hour); schedule flows accordingly. They are not marked billable because Datadog prices logs by ingestion, indexing and retention (Flex Logs by storage and a reserved compute tier), not per API query; querying the flex or online-archives tiers uses that capacity.
- Region: the connection's Datadog site (US1, US3, US5, EU1, AP1, AP2, UK1, US1-FED, US2-FED) selects the API host; keys only work on the site that issued them.
- Synthetic test request configuration (URLs, headers, credentials, variables) and dashboard widget definitions are not copied; only metadata and widget summaries are returned.
- Not implemented by design: deleting monitors, dashboards, SLOs, tests or incidents; muting or unmuting monitors (including mute-all); cancelling downtimes; triggering synthetic tests; on-call pages and the incident page endpoint; API key and application key management; user management.
- Dashboards, synthetics, teams, SLO corrections and catalog relations are read-only here; Datadog's create and update endpoints for them are not implemented.
- Incident todos and attachments use the Incidents v2 preview API.
- Monitor, incident, event and downtime creates have no idempotency key; uncertain writes are not repeated automatically.
Developer reference
- Create the Datadog credentials described above with the narrowest permissions your flows need.
- In Nexra, open Connect, then Connections, then New connection, choose Datadog, enter its settings and credentials, and tick only the write actions you need. Connection guide
- Test the connection, then use its actions as flow sources and destinations. Flow guide
Machine-readable detail: GET /api/public/connect/connectors/datadog and the Connections API.