Skip to content

[Feature][Plugin] Datadog Incident Management integration #9124

Description

@stigi

Search before asking

  • I had searched in the issues and found no similar feature requirement.

Use case

As an engineering leader using DevLake for DORA metrics, I want to ingest incidents from Datadog Incident Management, so that change failure rate and time to restore service keep working after a team moves its on-call off PagerDuty and onto Datadog.

DevLake already supports PagerDuty, Opsgenie, Rootly and incident.io. Datadog is a common destination for teams consolidating monitoring, paging and incident response in one tool, and today those teams lose their incident source when they migrate. The only path left is the generic webhook plugin, which cannot carry severity history, detection timestamps or per-incident custom fields.

Description

Datadog Incident Management exposes incidents through the public API (/api/v2/incidents,
paginated). Auth is the standard Datadog pair of an API key plus an application key,
against a site-specific host (api.datadoghq.com, api.datadoghq.eu, api.us3.datadoghq.com, …),
so the connection needs an endpoint or site field like other multi-region plugins.

Proposed plugin, modeled on incidentio and rootly:

  • Connection: API key + application key + site/endpoint.

  • Scope: incident types, analogous to the incident-type scope in the incident.io plugin.
    A single organization-wide scope is the fallback for orgs that do not use incident types.

  • Entities: incidents → domain issues with type = INCIDENT plus incidents.
    Field mapping, verified against a production Datadog organization:

    Datadog Domain
    public_id (and slug, e.g. IR-22) issue_key
    title title
    severity (SEV-1SEV-5, UNKNOWN) severity, via a configurable mapping
    state (active / stable / resolved) status, original_status
    created created_date
    detected detection timestamp, for time to detect
    resolved resolution_date, lead_time_minutes
    customer_impacted, customer_impact_duration impact attributes
    url url
    is_test excluded from collection, like incident.io's test/tutorial incidents
  • Custom fields: Datadog incidents carry both default fields (detection_method,
    root_cause, services, teams) and org-defined single-select, multi-select and
    free-text fields. The plugin would collect these verbatim into the tool layer, and the
    scope config would name which field maps onto component and which onto severity.
    The same shape as the deployment-name pattern in the CircleCI scope config. This keeps
    organization-specific vocabulary out of the plugin while making the fields usable for
    change-failure attribution.

  • No framework changes: the result feeds the existing DORA incident metrics.

Out of scope for a first PR: Datadog On-Call (schedules, pages, escalation policies),
monitors and alerts, and the Datadog DORA Metrics product.

We have mapped the fields above against our own production Datadog organization through
the API, and intend to implement the plugin in Go following the incidentio plugin layout
(models/raw, tool models with migration scripts, collector/extractor/converter tasks,
connection and scope APIs, e2e fixtures). Flagging the intent here first in case
maintainers want a different scope model or a different approach to the custom-field
mapping before we open the PR.

Related issues

Are you willing to submit a PR?

  • Yes I am willing to submit a PR!

Code of Conduct

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

type/feature-requestThis issue is a proposal for something new

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions