Firing Datadog and Coralogix alerts into Landfall
This page is about opening incidents automatically the moment a Datadog monitor or a Coralogix alert fires. It is not about reading telemetry — if you want the investigation agent to query your data once an incident already exists, see Connecting Coralogix or Connecting AWS instead. The two are independent, and most teams eventually set up both.
How it works
Both platforms send outbound webhooks whose body is a template you write, not a fixed schema. That is the whole reason this page exists: Landfall can only map an alert it recognizes, so the JSON you paste into your platform has to carry the field names below. Get the template right once and every subsequent alert works; get it wrong and you will see a 422 with no incident created.
Both platforms post to the same endpoint — POST /triggers — authenticated by a per-tenant bearer token. Landfall works out which platform sent the alert from the shape of the body, not from a URL path, a query parameter or a header, so there is one URL and one token for every source. The same endpoint also accepts CloudWatch alarms (see CloudWatch alerts).
What you'll need
- An admin seat on your Landfall organization, to mint the ingest token below.
- Permission to add an outbound webhook in Datadog (Integrations → Webhooks) or Coralogix (Integrations → Outbound Webhooks).
- At least one monitor or alert already configured — this guide doesn't create one.
1. Mint a trigger ingest token
This doesn't have a settings-page UI yet, so it's two API calls, made once with your own Landfall account: sign in to get a session token, then use that session token to mint the actual ingest token.
SESSION=$(curl -s -X POST https://api.landfalls.ai/auth/login \
-H "Content-Type: application/json" \
-d '{"email":"<you>","password":"<your password>","orgSlug":"<your-org>"}' \
| jq -r .accessToken)
curl -X POST https://api.landfalls.ai/o/<your-org>/triggers/ingest-token \
-H "Authorization: Bearer $SESSION"If your organization signs in through SSO instead, there is no password to hand curl: sign in normally in your browser, then open devtools and read localStorage.getItem('landfall.accessToken') for a session token to use as $SESSION above.
The response is { "token": "…" }. It is a separate, long-lived credential from the session token above, scoped to opening incidents in this one organization and nothing else. Landfall stores only its hash, so a lost token means minting a new one, which immediately invalidates the old one; there is no dual-valid window. The same token works for Datadog, Coralogix and CloudWatch — you do not need one per platform.
2. Datadog
In Datadog, go to Integrations → Webhooks and add a new webhook. Datadog requires custom headers to be JSON, which is how the bearer token gets attached.
| Name | landfall |
|---|---|
| URL | https://api.landfalls.ai/triggers |
| Custom headers | { "Authorization": "Bearer <your ingest token>", "Content-Type": "application/json" } |
| Encode as form | Leave unchecked — Landfall expects a JSON body |
Paste this into the Payload field:
{
"title": "$ALERT_TITLE",
"alert_type": "$ALERT_TYPE",
"priority": "$ALERT_PRIORITY",
"body": "$EVENT_MSG",
"tags": ["service:$TAGS[service]"]
}The obvious version — "tags": "$TAGS" — does not work for entity resolution, and it fails quietly. Datadog renders $TAGS as a comma-separated string, not a JSON array, and Landfall only reads tags when it is genuinely an array. Your incident would still open, but with no service attached to it. The per-key form $TAGS[service] pulls one tag's value, and wrapping it in a literal array gives Landfall the shape it reads. If the monitor has no service tag the entry renders empty and is skipped — harmless. Add more entries ("env:$TAGS[env]") if you want them carried as context.
What Datadog's fields become
| Template field | Datadog variable | Becomes |
|---|---|---|
| title | $ALERT_TITLE | The incident title. Defaults to "Datadog alert" if absent. |
| alert_type | $ALERT_TYPE | Severity when no priority is set: error → sev2, warning → sev3. |
| priority | $ALERT_PRIORITY | Severity, and it wins over alert_type: P1→sev1, P2→sev2, P3→sev3, P4/P5→sev4. |
| body | $EVENT_MSG | The summary line on the incident's first timeline event. |
| tags | $TAGS[key] | Entity context. A service:<name> entry resolves the incident to that service. |
Landfall recognizes a body as Datadog's when it carries an alert_type string or a tags array, so keep at least alert_type in the template even if you drop everything else.
3. Coralogix
In Coralogix, go to Integrations → Outbound Webhooks → Generic Webhook, then attach the webhook to the alerts you want to open incidents.
| Name | landfall |
|---|---|
| URL | https://api.landfalls.ai/triggers |
| Method | POST |
| Headers | { "Authorization": "Bearer <your ingest token>", "Content-Type": "application/json" } |
Paste this into the webhook body:
{
"alertName": "$ALERT_NAME",
"severity": "$EVENT_SEVERITY",
"applicationName": "$APPLICATION_NAME",
"subsystemName": "$SUBSYSTEM_NAME",
"query": "$QUERY_TEXT"
}What Coralogix's fields become
| Template field | Coralogix placeholder | Becomes |
|---|---|---|
| alertName | $ALERT_NAME | The incident title. Defaults to "Coralogix alert" if absent. |
| severity | $EVENT_SEVERITY | Critical→sev1, Error→sev2, everything else (Warning, Info)→sev3. Case doesn't matter. |
| applicationName | $APPLICATION_NAME | The service the incident is about. |
| subsystemName | $SUBSYSTEM_NAME | Carried as context; used as the service if applicationName is empty. |
| query | $QUERY_TEXT | The signal, shown in the incident's summary line. |
$QUERY_TEXT is empty for some metric alerts. Add "metricName": "$METRIC_KEY" to the body — Landfall falls back to it when there is no query, and it also feeds severity heuristics.
Recognition needs at least one of alertName, applicationName or subsystemName to be present and non-empty. A body carrying only generic fields like severity or query is deliberately not accepted as Coralogix — those names are too common to prove where the alert came from, and guessing would mean filing someone else's payload as a Coralogix incident.
4. Test it
Both platforms have a "test" button that sends the template with placeholder values, which is worth clicking. To check the mapping itself, post a realistic filled-in body yourself — this is exactly what your platform will send once the placeholders render:
curl -i -X POST https://api.landfalls.ai/triggers \
-H "Authorization: Bearer <your ingest token>" \
-H "Content-Type: application/json" \
-d '{
"title": "[P2] 5xx rate above 2% on web-edge",
"alert_type": "error",
"priority": "P2",
"body": "5xx rate 4.1% over the last 5 minutes, threshold 2%.",
"tags": ["service:web-edge"]
}'Opens an incident titled [P2] 5xx rate above 2% on web-edge at sev2 (from P2), about the service web-edge.
curl -i -X POST https://api.landfalls.ai/triggers \
-H "Authorization: Bearer <your ingest token>" \
-H "Content-Type: application/json" \
-d '{
"alertName": "Checkout error spike",
"severity": "Critical",
"applicationName": "checkout",
"subsystemName": "payments",
"query": "level:error AND service:checkout"
}'Opens an incident titled Checkout error spike at sev1 (from Critical), about the service checkout.
Troubleshooting
| What you see | What it means |
|---|---|
| 401 | The token is missing, malformed or no longer current. Minting a new ingest token invalidates the previous one — check you pasted the latest. |
| 422 | The body matched none of the three known shapes, and no incident was created. Almost always a template that lost its identifying fields — keep alert_type for Datadog, and one of alertName/applicationName/subsystemName for Coralogix. |
| An incident opens, but with no service on it | For Datadog, the "tags": "$TAGS" mistake above. For Coralogix, an empty $APPLICATION_NAME — check the alert actually filters on an application. |
| A malformed-JSON error from your platform | Usually a free-text placeholder ($EVENT_MSG, $ALERT_DESCRIPTION) whose content contains a newline or a quote. Drop that field from the template to confirm, then add it back last. |
| Two incidents for one problem | Every delivery opens its own incident: there is no dedup and no auto-close on recovery. If your monitor notifies on both trigger and recovery, restrict the webhook to the trigger transition in the platform. |
Reference
| Endpoint | POST https://api.landfalls.ai/triggers |
|---|---|
| Auth | Authorization: Bearer <ingest token> identifies the organization directly; there is no org path parameter |
| Mint a token | POST https://api.landfalls.ai/o/<your-org>/triggers/ingest-token |
| Accepted shapes | Datadog webhook, Coralogix alert, CloudWatch alarm — one endpoint, one token |
| Each delivery | Opens one new incident: no dedup, no auto-close on recovery |
| Rejected payloads | 422, no incident created; a missing or invalid token is a uniform 401 |