Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Feature][Plugin] Datadog Incident Management integration

Abierto
  • ¿Algo no está bien?
#9,124 3 comentarios 1 reacción 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@stigi ya está trabajando en esto.

Desde el 11/9/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

type/feature-request
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-1…SEV-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
  • #9023 - incident.io plugin, the closest precedent for scope and field mapping
  • #8877 - Rootly plugin
Are you willing to submit a PR?
  • Yes I am willing to submit a PR!
Code of Conduct
Lenguaje dominante
Go
Estrellas
3.1k
Forks
812
Merge medio
2 d 8 h
PR fusionados (30 d)
51

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/devlake

Todos los issues de apache/devlake

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.