Opening a war room from a Coralogix alert

A Coralogix outbound webhook can open a Landfall incident the moment an alert fires. This page is not about reading telemetry; for that, see Connecting Coralogix to Landfall. The two are independent.

How it works

Coralogix posts each alert to POST https://api.landfalls.ai/triggers with the header Authorization: Bearer <ingest token>. The token belongs to one organization and decides where the incident opens, so the URL carries no organization name. A missing or unknown token gets a 401 and opens nothing.

CloudWatch, Datadog and Sentry alerts use the same endpoint and the same token. Landfall tells them apart by the body. A body with a non-empty alertName, alert_severity, applicationName, subsystemName or logQuery is read as Coralogix's. CloudWatch and Datadog are checked first, so a body that also carries an alert_type string or a tags array is read as Datadog's.

A Coralogix delivery carries no alert identity, so nothing attaches. Every delivery opens its own incident.

What you'll need

• An owner or admin of your Landfall organization, to mint the ingest token.
• curl and jq, for the two calls in step 1.
• In Coralogix, access to Integrations → Outbound Webhooks and to the alerts that should open incidents.
• Optional: the Coralogix source connection, so Beacon can query the logs the alert came from.

1. Mint the ingest token

No screen issues this token yet, so it is two calls made with your own Landfall account. The first signs in, the second issues the token. If you already minted one for CloudWatch, Datadog or Sentry, reuse it. One token serves every source on this endpoint.

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"

The answer is {"token": "<64 hex characters>"}. It is shown once, and Landfall keeps only a hash of it. A personal API key for this organization (Your settings → API keys) can stand in for $SESSION.

Minting again replaces the token at once, and the old one stops working everywhere it was set, so update every webhook that uses it. Each issue is recorded in the audit log as trigger.ingest_token.issued.

2. Point Coralogix at Landfall

1. Integrations → Outbound Webhooks → Generic Webhook

   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:

   Webhook bodyCopy

   {
     "alertName": "$ALERT_NAME",
     "severity": "$EVENT_SEVERITY",
     "applicationName": "$APPLICATION_NAME",
     "subsystemName": "$SUBSYSTEM_NAME",
     "query": "$QUERY_TEXT"
   }

   Metric alerts

   $QUERY_TEXT is empty for some metric alerts. Landfall reads query first and does not skip an empty one, so give metric alerts a second webhook whose body has "metricName": "$METRIC_KEY" in place of "query". Landfall falls back to metricName when the body has no query.

2. Attach it to your alerts

   In each alert that should open an incident, add the landfall webhook to its notifications.

What Coralogix's fields become

A body counts as Coralogix's only when one of alertName, alert_severity, applicationName, subsystemName or logQuery is present and non-empty. A body with only generic fields such as severity or query is rejected on purpose. Those names are too common to prove where the alert came from, and a guess would file someone else's payload as a Coralogix incident.

3. Test it

Send one alert by hand. This body is what the template above looks like once Coralogix fills it in:

curl -i -X POST https://api.landfalls.ai/triggers \
  -H "Authorization: Bearer <your ingest token>" \
  -H "Content-Type: application/json" \
  -d '{
    "alertName": "Checkout error rate above 5%",
    "severity": "Error",
    "applicationName": "checkout",
    "subsystemName": "api",
    "query": "level:error"
  }'

The answer is 201 with "outcome": "opened", "entity": {"kind": "service", "id": "checkout"}, "proposedSeverity": "sev2" from Error, and a workspaceUrl that opens the room. The new row in Incidents carries the Coralogix badge. Send the same body again and a second incident opens. The incidents are real, so resolve them when you are done.

Repeats and recovery

• Attach identity: none. Coralogix deliveries carry no alert id Landfall reads, so it cannot tell a repeat from a new alert.
• Repeat: every delivery opens a new incident, including a second notification for an alert that is still firing.
• Recovery: Landfall records no recovery for Coralogix. If an alert notifies this webhook when it resolves, that delivery opens another incident too.
• Landfall never resolves a room on its own. A person resolves it.

Troubleshooting

Reference

How this endpoint sits beside the other trigger paths: Integrations architecture.