Skip to content
downpipes docs

Forward the downpipes audit trail to Datadog

Datadog receives the downpipes audit trail through its Logs intake API. The engine dials out to your Datadog logs endpoint on the scheduler tick and posts each batch as a JSON array of log objects, and Datadog auto-facets the fields on arrival, so events are searchable straight away with nothing to map by hand. Along with Splunk, this is one of the two targets that parse a first-time feed for you.

Because the engine makes the outbound call, a Cloudflare Access perimeter on your console hostname never blocks this: there is no inbound request for Access to turn away.

What you need

  • A Datadog role that can create an API key (a standard API Keys admin permission).
  • Your Datadog site’s logs intake URL, and owner access to the downpipes console.

Set it up

  1. In Datadog, create an API key: open API Keys in your organisation settings, add a key, and copy its value.
  2. Note the logs intake URL for your Datadog site. For US1 it is https://http-intake.logs.datadoghq.com/api/v2/logs; the EU, US3, US5 and AP1 sites use a different host, shown on Datadog’s own Logs intake docs for your site.
  3. In the downpipes console, open Integrations, choose this vendor’s tile, and set up the SIEM audit push there (owner-only, asks for a fresh step-up sign-in).
  4. Set the sink to HTTPS endpoint, the format to Datadog Logs intake, and paste your intake URL.
  5. Set the auth header name to DD-API-KEY and paste the API key as its value. Datadog reads the key from that header, with no prefix added.
  6. Choose Test send. The engine posts one synthetic audit-shaped event and reports Datadog’s honest response. A test send never advances the delivery cursor.
  7. With the test accepted, Enable the destination. From the next scheduler tick, the engine forwards every audit event above the cursor.

What lands in Datadog

Each batch arrives as a JSON array of Datadog log objects. Every object carries ddsource, service, a message (the action and outcome), a status mapped from the outcome, and the audit event’s own fields alongside:

[{"ddsource":"downpipes","service":"downpipe-engine","message":"restore-approve success","status":"info","seq":4097,"action":"restore-approve","outcome":"success","actorEmail":"ops@acme.example","...":"..."}]

Datadog facets those attributes on arrival, so a query like service:downpipe-engine @action:restore-approve works immediately. The status is error for a failed event, warning for a denied one, and info otherwise, so a failed or denied action reads correctly in the severity facet.

Good to know

  • Datadog’s intake caps a request at 1000 items or 5 MB. The engine drains up to 500 events per scheduler tick, well under that, and a larger backlog drains over successive ticks rather than in one oversized request.
  • Delivery is at-least-once, not exactly-once. Every event carries a stable seq and hash, so a re-sent event is a duplicate you drop on either. The feed carries operator identity (member emails, source IPs, roles and approver emails); no backup data and no secret values. For the shared push mechanics and the pull alternative, see forwarding the audit log to your SIEM.

Last updated .