Webhook field mapping
When you move a custom outbound-webhook body to Notification Center, you rebuild it as a custom preset with Tera. This page maps each legacy webhook placeholder to its Notification Center field for Case notifications.
If you use a system preset, you do not need this mapping. System presets already produce a correct payload. Use this page only when you build a custom preset or a custom webhook body.
How to read this page
Each row lists a legacy placeholder and the Tera path that renders the same value in a Case-notification preset. Paths that read from an alert indicator use case.indicators.alerts[0], the first indicator on the Case. A Case can hold more than one indicator, so reference the first one explicitly with [0]. For the full structure these paths resolve against (handy when generating a preset with an AI assistant), see Example Case payload.
Alert identity, state, and priority
| Legacy placeholder | Case notification | Notes |
|---|---|---|
$ALERT_ACTION | case.status (indicator: case.indicators.alerts[0].state) | Lifecycle state, for example TRIGGERED or RESOLVED |
$ALERT_EVENT_ID | case.indicators.alerts[0].instanceId | The specific alert event that triggered the notification |
$ALERT_ID | case.indicators.alerts[0].alertDefinitionVersionId | Versioned alert-definition identifier |
$ALERT_UNIQUE_IDENTIFIER | case.id, or case.indicators.alerts[0].alertDefinitionId | Stable alert-definition identifier |
$ALERT_DESCRIPTION | case.indicators.alerts[0].description | |
$ALERT_PRIORITY, $EVENT_SEVERITY | case.priority (indicator: case.indicators.alerts[0].priority) | Priority P1 to P5 |
$EVENT_SEVERITY_LOWERCASE | case.priority | lower | The priority in lower case, for integrations that require it |
Condition and query
| Legacy placeholder | Case notification | Notes |
|---|---|---|
$ALERT_THRESHOLD | case.indicators.alerts[0].threshold | Configured threshold that must be crossed |
$TIMEFRAME | case.indicators.alerts[0].timeWindow | Evaluation window |
$METRIC_CRITERIA | case.indicators.alerts[0].threshold, .timeWindow, .details.countOverThreshold | Full metric condition |
$TIMEFRAME_OVER_THRESHOLD | case.indicators.alerts[0].details.fromTimestamp to .toTimestamp | Window during which the condition was violated |
$DEFINED_RATIO_THRESHOLD | case.indicators.alerts[0].threshold | Ratio alerts |
$RELATIVE_QUERY_TEXT | case.indicators.alerts[0].alertQuery.queryString | Time-relative alerts |
$RELATIVE_HIT_COUNT | case.indicators.alerts[0].details.relativeHitCount | Denominator match count in a ratio alert |
$SLO_THRESHOLD | case.indicators.alerts[0].threshold | SLO alerts |
Log example fields
Read each field directly from the log example on the alert indicator.
| Legacy placeholder | Case notification |
|---|---|
$LOG_TEXT | case.indicators.alerts[0].details.logExample.text |
$CATEGORY | case.indicators.alerts[0].details.logExample.category |
$APPLICATION_NAME | case.indicators.alerts[0].details.logExample.applicationName |
$SUBSYSTEM_NAME | case.indicators.alerts[0].details.logExample.subsystemName |
$SERVICE | case.indicators.alerts[0].details.logExample.service |
$COMPUTER_NAME | case.indicators.alerts[0].details.logExample.computerName |
$IP_ADDRESS | case.indicators.alerts[0].details.logExample.ipAddress |
Grouping, labels, timing, and general
| Legacy placeholder | Case notification | Notes |
|---|---|---|
$GROUP_BY_FIELD_#, $GROUP_BY_VALUE_#, $ALERT_GROUP_BY_VALUES | case.indicators.alerts[0].groupings | The full grouping is exposed as an object, which replaces the numbered placeholders. Pipe through | json_encode to render it as text |
$NO_DATA_GROUP_BY_VALUES | Loop the indicators and guard on isNoData: {% for a in case.indicators.alerts %}{% if a.isNoData %}{{ a.groupings | json_encode }}{% endif %}{% endfor %} | Groups that fired because the query returned no data (there is no bare filter syntax; iterate and test isNoData) |
$META_LABELS, $META_LABELS_LIST | case.labels, or _context.entityLabels | Both are array-shaped ({key: [values]}); index a single value with ["key"][0], or add | json_encode(pretty = true) for a formatted list |
$EVENT_TIMESTAMP | case.indicators.alerts[0].details.logExample.timestamp | Log timestamp (ISO 8601) |
$EVENT_TIMESTAMP_MS | case.updatedAt | date(format = "%s000") | Milliseconds |
$TEAM_NAME | _context.system.name | Organization or team name |
$RESOLVED_AWARE_DEDUP_KEY | correlationKey (top-level), or case.id | Stable per-Case key. Use it as the dedup key for PagerDuty or ServiceNow-style integrations — this is what the system PagerDuty preset uses |
Placeholders without a Notification Center field
$CORALOGIX_ICON_URLis a fixed value in Notification Center, so there is no dynamic field to map.- These legacy placeholders have no Notification Center equivalent yet:
$DURATION,$ERRORS,$METRIC_OPERATOR,$RATIO_GROUP_BY_TABLE, and$SPANS. $RATIO_QUERY_ONEand$RATIO_QUERY_TWO(numerator and denominator queries) are pending confirmation of the exact indicator path and are not yet mapped.
Example Case payload
This is an example of the data a Case notification exposes to a preset, so you can see the structure the Tera paths above resolve against. It is also a useful reference to hand to an AI assistant such as Olly when generating a preset: point it at this page and it can map fields to paths directly. Values are illustrative; the example shows a metric-threshold alert indicator, and other alert types populate the same structure with type-specific fields.
{
"case": {
"id": "76c411be-ff4d-4fb1-a987-5fce042deaaf",
"title": "Test Case",
"description": "This is the description of the Test Case",
"url": "https://team.coralogix.com/#/cases?id=CASE-123",
"status": "ACKNOWLEDGED",
"priority": "P4",
"category": "AVAILABILITY",
"createdAt": "2025-08-10T09:15:00Z",
"updatedAt": "2025-08-10T09:20:00Z",
"labels": { "team": ["platform"], "env": ["prod"] },
"groupings": { "service": ["payment-api"], "region": ["us-west-2"] },
"indicators": {
"alerts": [
{
"instanceId": "instance-id-1",
"alertDefinitionId": "987e4567-e89b-12d3-a456-426614174111",
"alertDefinitionVersionId": "ver12345-6789-abcd-ef01-234567890abc",
"title": "Test CPU Alert",
"description": "Triggers when average CPU usage on payment-api exceeds 80% over a 5-minute window.",
"alertType": "METRIC_THRESHOLD",
"priority": "P4",
"groupingType": "COMBINATION_ALERT",
"groupByKeys": ["service", "region"],
"timeWindow": 300,
"threshold": 80.0,
"groupings": { "service": "payment-api", "region": "us-west-2" },
"labels": { "metric": "cpu", "team": "platform" },
"state": "TRIGGERED",
"isNoData": false,
"triggeredAt": "2025-08-10T09:14:00Z",
"resolvedAt": null,
"alertQuery": {
"queryString": "avg(node_cpu_seconds_total{mode=\"system\",service=\"payment-api\"}) > 0.8",
"type": "ALERT_QUERY_PROMQL"
},
"details": {
"fromTimestamp": "2025-08-10T09:09:00Z",
"toTimestamp": "2025-08-10T09:14:00Z",
"countOverThreshold": 12,
"relativeHitCount": null,
"valueOverThreshold": 83.7,
"uniqueCountValuesList": null,
"logExample": {
"text": "ERROR: CPU usage at 83.7% on payment-api pod prod-worker-03",
"applicationName": "payment-service",
"subsystemName": "checkout",
"service": "payment-api",
"ipAddress": "10.0.1.21",
"computerName": "prod-worker-03",
"threadId": "main-thread",
"timestamp": "2025-08-10T09:13:45Z",
"category": "ERROR",
"logId": "log-def456abc789"
}
}
}
]
}
},
"_context": {
"system": { "id": "team-1234", "name": "onlineboutique" },
"entityLabels": { "service": ["payment-api"] }
},
"caseMetadata": {
"notificationReason": "caseUpdated",
"change": { "$type": "statusChanged", "previousStatus": "ACTIVE", "currentStatus": "ACKNOWLEDGED" }
},
"correlationKey": "76c411be-ff4d-4fb1-a987-5fce042deaaf",
"name": "Test Case",
"priority": "P4"
}