Reference · built on requestConnectorIdentity, IT & observability

Datadog

Metrics, monitors, events, logs, SLOs, and incidents from a Datadog organization through the Datadog API with API and application keys.

Request accessPricing ↗

About

Datadog is a monitoring and security platform for infrastructure, applications, and logs. Its REST API runs on the site your organization belongs to, such as api.datadoghq.com, api.us3.datadoghq.com, api.us5.datadoghq.com, api.datadoghq.eu, api.ap1.datadoghq.com, or api.ddog-gov.com, with v1 and v2 endpoints for metrics, monitors, events, logs, service level objectives, and incidents. The Webhooks integration lets a monitor notify a URL with @webhook-<name>.

Through Fibric, an operator reads monitor state, events, and SLO history and proposes a monitor mute, an incident, or an event on the timeline. You approve it on the page, and the receipt holds the monitor or incident id and the way to reverse it.

This is a reference listing. It documents what Fibric would read from Datadog and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Monitors through GET /api/v1/monitor, /api/v1/monitor/{monitor_id}, /api/v1/monitor/search, and /api/v1/monitor/groups/search
  • Events through GET /api/v2/events and POST /api/v2/events/search
  • Timeseries through GET /api/v1/query and POST /api/v2/query/timeseries, plus the active metric list at GET /api/v1/metrics
  • Logs through POST /api/v2/logs/events/search, GET /api/v2/logs/events, and POST /api/v2/logs/analytics/aggregate
  • Service level objectives through GET /api/v1/slo and their history at /api/v1/slo/{slo_id}/history
  • Incidents, attachments, todos, and responders through /api/v2/incidents
  • Monitor notifications delivered to a URL by the Webhooks integration, with $ALERT_ID, $ALERT_TRANSITION, $ALERT_STATUS, $EVENT_TITLE, $HOSTNAME, and $TAGS

Proposed actions

  • Target capability: propose Mute a monitor or Unmute a monitor through POST /api/v1/monitor/{monitor_id}/mute or /unmute
  • Target capability: propose Create an incident or Update an existing incident through /api/v2/incidents
  • Target capability: propose Post an event through POST https://event-management-intake.{site}/api/v2/events
  • Target capability: propose Edit a monitor through PUT /api/v1/monitor/{monitor_id}, checked first with POST /api/v1/monitor/validate

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Open the incident while the pager is still ringing

    A webhook with $ALERT_TRANSITION Triggered arrives. The operator pulls the monitor and the last events on the host, then proposes Create an incident with those ids attached. You approve it from the page.

    With Uptime Response

  • Quiet the monitors that never mean anything

    Monitors search and the events feed show which monitors flap. The operator proposes Mute a monitor with an end time, or an Edit a monitor threshold change, each with the flapping evidence.

    With Alert Noise

  • Know the error budget before you ship

    SLO history from /api/v1/slo/{slo_id}/history is read for the window you name. The operator posts the remaining budget and proposes a hold when it is spent.

    With Error Budget

  • Hand over on-call with the facts

    Open incidents, muted monitors, and the events of the last shift are collected into one handoff note, proposed as a Post an event entry on the timeline for the incoming engineer.

    With On-call Handoff

Requirements

  • A Datadog organization and its site host; sites are independent and data does not cross them
  • An API key, and an application key scoped to the least privileges the operator needs, created by a user with org_app_keys_write or user_app_keys
  • A Webhooks integration entry with your URL, referenced as @webhook-<WEBHOOK_NAME> in the monitors that should notify it
  • A successful GET /api/v1/validate with the key pair before the first read
Authentication
A DD-API-KEY header with an organization API key plus a DD-APPLICATION-KEY header with an application key, which carries the creating user's permissions unless scoped to specific authorization scopes.

Limits

  • Rate limits vary by endpoint and return 429 with X-RateLimit-Limit, X-RateLimit-Period, X-RateLimit-Remaining, X-RateLimit-Reset, and X-RateLimit-Name headers
  • Event submission is limited to 250,000 events per minute per organization; metric and log submission are not rate limited
  • Metric payloads are capped at 500 kilobytes uncompressed or 5 megabytes compressed, with timestamps up to 10 minutes ahead or 1 hour behind
  • Read endpoints need both keys; an application key inherits its creator's permissions unless scoped

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Datadog ↗

Questions and answers

Which keys does the connector need?
Two. An API key, which is unique to the organization and sent as DD-API-KEY, and an application key sent as DD-APPLICATION-KEY. Write endpoints need the API key; read endpoints need both. Application keys default to the creating user's permissions and can be scoped to specific authorization scopes.
How does Datadog push alerts?
Through the Webhooks integration. You name a webhook with a URL, then add @webhook-<WEBHOOK_NAME> to a monitor's notification text. Datadog POSTs JSON with variables such as $ALERT_ID, $ALERT_STATUS, $ALERT_TRANSITION, $EVENT_TITLE, $HOSTNAME, and $TAGS. Custom payloads, custom headers, Basic HTTP, and OAuth 2.0 are supported.
Which site does my organization use?
One of US1 (datadoghq.com), US3, US5, EU1 (datadoghq.eu), AP1, AP2, US1-FED (ddog-gov.com), or US2-FED. Each site is independent and data cannot be shared across sites. Your site is shown on the My Preferences page, and the API host follows it, for example api.datadoghq.eu.
Ask about Datadog

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Datadog through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy