DIY Coralogix Integration: Alert Automation with Native Tools

A flow alert fires at 09:47. It caught exactly what you designed it to catch: the deploy marker for checkout v2.14, followed within ten minutes by a 5xx threshold breach, followed by a latency alert on the same subsystem. Three signals, in sequence, correlated by Coralogix before anyone looked. Then you open the runbook, and step four says: investigate manually.

That gap between a well-built alert and an investigated answer is what this article works on. Part one mapped where triage time actually goes on Coralogix. This part is the hands-on build: a DIY Coralogix integration for alert automation using only native features. Alert definitions, notification routing, outbound webhooks, the Alerts API, DataPrime and TCO policies. Nothing to install, no third-party glue. Budget an afternoon for the first pass.

We'll go feature by feature, because each one removes a different piece of manual work:

01Define

Alerts

Ratio, new-value and flow alerts that carry their own meaning.

02Deliver

Webhooks

A templated payload with a deep link and a sample log line.

03Govern

Alerts API

Definitions in git, changed through pull requests.

04Enrich

DataPrime

The same triage queries, run by a script when the alert fires.

05Route

TCO policies

Investigation context kept hot, chatter kept cheap.

---

Tool 1: Alert definitions that carry their own meaning

The cheapest triage automation is an alert that doesn't need interpreting. Coralogix gives you several alert types beyond a simple threshold (docs). Three of them do most of the work at SaaS scale.

Threshold alerts are the baseline: more than N matching logs (or a metric past a value) in a time window. Console: Alerts → Alert Management → New Alert → Logs → Threshold. The mistake to avoid is alerting on raw counts for anything traffic-correlated. A fixed "50 errors in 10 minutes" fires all day during a marketing campaign and never fires at 3 a.m. when 40% of requests are failing.

Ratio alerts fix that. You define two queries, say query A is status_code:[500 TO 599] and query B is all requests on the same subsystem, and alert when A/B crosses a percentage. An error rate over 5% means the same thing at any traffic level, so the alert stays meaningful without seasonal re-tuning.

Flow alerts chain other alerts into an ordered sequence with time constraints: "deploy-marker alert, then 5xx-ratio alert within 10 minutes, then p99-latency alert within 5 more." A flow alert firing is worth ten individual alerts firing, because the sequence is the preliminary diagnosis. It's the difference between "errors are up" and "errors went up right after a deploy and latency followed."

Notification groups are the last piece of definition-level automation. Instead of one alert definition per service, group notifications by a key (typically subsystemName) and one ratio alert fans out into separate, per-service notifications, each carrying only that service's matching logs. One definition to maintain, per-service context on delivery.

Tool 2: Outbound webhooks that deliver context, not a ping

By default an alert notification tells you that something fired. A custom webhook payload makes it tell you what fired, where and how bad. That's the difference between opening Slack and opening Slack, then Coralogix, then three more tabs.

Coralogix outbound webhooks (console: Data Flow → Outbound Webhooks) ship native integrations for Slack, PagerDuty, Opsgenie and others, plus a generic webhook with a fully templated body (docs). A generic payload worth copying:

{
  "alert": "$ALERT_NAME",
  "description": "$ALERT_DESCRIPTION",
  "priority": "$ALERT_PRIORITY",
  "application": "$APPLICATION_NAME",
  "subsystem": "$SUBSYSTEM_NAME",
  "hit_count": "$HIT_COUNT",
  "fired_at": "$EVENT_TIMESTAMP",
  "permalink": "$ALERT_URL",
  "sample_log": "$LOG_TEXT"
}

Two fields earn their place. $ALERT_URL is a deep link straight to the firing alert's context in Coralogix, so nobody hunts through the UI. $LOG_TEXT is a sample of the matching log, so the on-call engineer sees an actual error message on their phone, not a metric name.

Point this at Slack for people, or at any HTTP endpoint for machines: a Lambda that opens a Jira ticket, a runbook automation trigger, an internal triage service. The webhook is Coralogix's only outbound hand-off point, so anything you automate downstream starts here.

Tool 3: The Alerts API, definitions as code

Twenty alert definitions maintained by hand in a UI drift. Thresholds get "temporarily" loosened, notification targets go stale, nobody remembers why the ratio is 7%. The Alerts API lets you keep definitions in git and apply them like any other config (docs).

Creating a threshold alert with the v3 alert-definitions endpoint:

curl -X POST "https://api.coralogix.com/mgmt/openapi/v3/alert-defs" \
  -H "Authorization: Bearer $CX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "alertDefProperties": {
      "name": "checkout-5xx-threshold",
      "description": "More than 50 5xx logs from checkout in 10 minutes",
      "priority": "ALERT_DEF_PRIORITY_P2",
      "type": "ALERT_DEF_TYPE_LOGS_THRESHOLD",
      "logsThreshold": {
        "rules": [{
          "condition": {
            "threshold": 50,
            "timeWindow": { "logsTimeWindowSpecificValue": "LOGS_TIME_WINDOW_VALUE_MINUTES_10" },
            "conditionType": "LOGS_THRESHOLD_CONDITION_TYPE_MORE_THAN"
          }
        }],
        "logsFilter": {
          "simpleFilter": {
            "luceneQuery": "status_code:[500 TO 599]",
            "labelFilters": {
              "subsystemName": [{ "value": "checkout", "operation": "LABEL_FILTER_OPERATION_TYPE_IS" }]
            }
          }
        }
      }
    }
  }'

List everything you have with GET on the same endpoint. Two practical notes. Swap api.coralogix.com for your region's domain (api.eu2.coralogix.com, api.coralogix.us and so on). And create a dedicated API key scoped to alert management only, not your team's do-everything key.

Once definitions live in a repo, threshold changes become pull requests. That alone kills the "who changed this alert and why" archaeology that eats an hour of every incident retro.

Tool 4: DataPrime, the questions you ask when it fires

The webhook told you checkout is throwing 5xx. Now come the triage queries, the ones you run every single time, which is exactly why they belong in a saved view or a script and not in someone's muscle memory. DataPrime (docs) is Coralogix's pipe-based query language: $m is metadata, $l is labels, $d is your log's own fields.

Which status codes, on which paths:

source logs
| filter $l.subsystemname == 'checkout' && $d.status_code >= 500
| groupby $d.path aggregate count() as hits
| orderby hits desc
| limit 10

Is it one service or several (the blast-radius check):

source logs
| filter $m.severity == ERROR
| groupby $l.subsystemname aggregate count() as errors
| orderby errors desc

What changed in the error mix. Run this over the incident window, then over the same window yesterday, and diff the output:

source logs
| filter $l.subsystemname == 'checkout' && $m.severity == ERROR
| groupby $d.message aggregate count() as occurrences
| orderby occurrences desc
| limit 20

You can run all of these programmatically through the Direct Query HTTP API (docs), which is how you wire "alert fired" to "context gathered" without a person in between:

curl -X POST "https://api.coralogix.com/api/v1/dataprime/query" \
  -H "Authorization: Bearer $CX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "source logs | filter $l.subsystemname == '\''checkout'\'' && $m.severity == ERROR | groupby $d.status_code aggregate count() as hits | orderby hits desc",
    "metadata": {
      "tier": "TIER_FREQUENT_SEARCH",
      "startDate": "2026-07-13T09:40:00Z",
      "endDate": "2026-07-13T10:10:00Z"
    }
  }'

Putting it together: the 09:47 receiver

Here's what the full native build does with the flow alert from the opening. The generic webhook posts its payload to a small receiver you host. The receiver reads subsystem and fired_at, runs the three DataPrime queries above for a 30-minute window around fired_at, and posts one Slack message: the alert name, the permalink, the top five status codes by path, and the error messages that are new compared with yesterday.

That's a genuinely good afternoon project. Your on-call opens Slack and sees 412 hits on /api/checkout/complete, with an error message that didn't exist yesterday, two minutes after a deploy. It's also where most teams' DIY automation plateaus, for reasons covered below.

Tool 5: TCO policies that keep triage data hot

None of the above works if the logs you need at 09:47 were routed somewhere slow. Coralogix's TCO Optimizer (console: Data Flow → TCO Optimizer, docs) assigns logs to one of three pipelines by policy, matching on application, subsystem and severity:

• Frequent Search: fully indexed, instant queries. The expensive tier.
• Monitoring: processed for alerting and dashboards. Queries run against the archive, slower but far cheaper.
• Compliance: stored for audit. Cheapest, not for triage.

The pattern that keeps both the bill and the blind spots down: route ERROR and CRITICAL from production-critical subsystems to Frequent Search. Route INFO from those same subsystems to Monitoring (alerts still evaluate against it). Route DEBUG and non-prod chatter to Compliance, or drop it. Alerts fire regardless of tier, but your investigation speed depends on where the surrounding context lives. A team that sends everything to Frequent Search overpays, typically by a wide margin. A team that sends checkout's errors to Compliance finds out during an incident.

Revisit the policies quarterly. New subsystems land in default policies, and defaults are never what you'd choose deliberately.

---

What each layer removes, and what it leaves

The pattern in the right-hand column is the point. Each layer automates a step you already knew you'd take. None of them decides which step to take next.

The ceiling: context isn't a conclusion

Build all five layers and you have something real: alerts that mean something, notifications that carry evidence, definitions under version control, triage queries one command away, and the underlying data kept queryable. That's a solid Coralogix alerting setup. Here's where it stops:

01Interpretation

Context only

Webhooks carry evidence. A person still decides what it means.

02Horizon

Coralogix only

Node failures, failovers and flag flips never reach the telemetry.

03Branching

Pre-scripted

The receiver runs the queries you wrote last quarter, nothing more.

04Upkeep

Yours

Thresholds, payloads and TCO policies all drift without an owner.

Webhooks deliver context; they don't interpret it. Your payload says 412 hits on /api/checkout/complete. Whether that's the payment provider, the deploy, or a poison message in a queue is still a person's call.

Coralogix correlates within Coralogix. A flow alert can sequence Coralogix alerts, but it can't see that a Kubernetes node went NotReady, that an RDS failover ran, or that a feature flag flipped. The cloud-side state that explains most incidents lives outside the telemetry.

Every automation here is pre-scripted. Your webhook receiver runs the three queries you wrote last quarter. The first incident that needs a fourth query is back to manual, at 3 a.m., under pressure.

The engineer-hours never go to zero. Alert definitions drift, thresholds need re-tuning, TCO policies need revisiting. Each layer is maintenance you own.

The DIY stack gets an alert from "something fired" to "here's the evidence," and stops. Getting from evidence to an investigated answer, every time, is a different kind of system.

What comes next

Everything after the webhook (querying the incident window, choosing the next query from what the last one returned, correlating with deploys and cloud-side state, naming a likely cause with evidence attached) is what part three of this series covers. It uses CloudThinker connected to Coralogix with a read-only, scoped API key. Nothing changes in your systems unless a named person approves it, or a policy you wrote already covers it under Auto Mode.

If you skipped part one, it covers which alert types and TCO routing decisions to get right before building any of this.

Or see it against your own alerts first: Try CloudThinker free with 100 premium credits and no card required.