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 a human ever 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. In part one of this series we 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.
Tool 1: Alert definitions — make the alert carry its 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 — deliver context, not just 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 — which is 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"
}
The two fields that earn their place: $ALERT_URL, a deep link straight to the firing alert's context in Coralogix (no hunting through the UI), and $LOG_TEXT, 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 humans, 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 per incident retro.
Tool 4: DataPrime — the questions you ask when it fires
The webhook told you checkout is throwing 5xx. Now the triage queries — the ones you run every single time, which is precisely why they belong in a saved view or a script, 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 human 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"
}
}'
A webhook receiver that runs these three queries and posts the results into the incident channel is a genuinely good afternoon project. It's also where most teams' DIY automation plateaus — more on that below.
Tool 5: TCO policies — keep the data you triage on 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 — match 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 entirely 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.
The ceiling: context is not a conclusion
Build all five layers and you'll 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 — and it's worth being honest about where it stops.
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 human'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 investigated answer, consistently, is a different kind of system.
What comes next
Everything after the webhook — querying the incident window, correlating with deploys and cloud-side state, naming a likely cause with evidence attached — is what part three of this series covers, using CloudThinker agents connected to Coralogix with a read-only, scoped API key. Nothing changes in your systems without the autonomy level you configure allowing it.
Or see it against your own alerts first: Try CloudThinker free — 100 premium credits, no card required.