Connections — Feature Guide

1. What is this feature?

A Connection is a reusable HTTP recipe — a URL, headers, a request template, and a set of response mappings — that the alert ingest pipeline can call to enrich incoming alerts with external context.

The problem it solves: alerts arrive with limited information (e.g. just a host IP). Connections let you reach out to an external system (CMDB, asset inventory, internal API, etc.) at ingest time and fold the answer back into the alert — so by the time a responder sees the alert, it already shows the owning service, environment, region, runbook link, and so on.

A Connection only runs when a Routing rule opts into it through the new "Enrich from connection" action (CONNECTION_ENRICHMENT). The rule references a connection by id; the connection's own response mappings are applied automatically.

The mental model in one line

Read a field from the alert → call an external HTTP endpoint with it → copy something from the response back into the alert.

Two pieces, two places

Piece	Where it lives	What it does
Connection	Settings → Configuration → Connections	Defines the HTTP recipe + what to copy back
Routing action	Settings → Routing → Default Attribute	Tells a rule branch to run a connection when conditions match

2. Anatomy of a Connection

The create/edit dialog is organized as three explicit steps that mirror the data flow.

Connection form dialog — the three steps

Step 1 · Pick alert fields to use in the request

Bind values out of the incoming alert payload to short variable names you can reuse.

Read from payload — a dot-path into the alert (e.g. metadata.host).
Call it — a short name (e.g. HOST). You then reference it as $HOST in Step 2.
A provider dropdown shows a real example payload (HTTP, Opsgenie, Prometheus, Datadog, …), defaulting to http, so you can see exactly which paths exist before binding them. (This reuses the same example payloads as the webhook setup page.)

Step 2 · Build the request

The editor adapts to the HTTP method: