--- title: Notification settings description: 'Decide what an alert is for: open a Case, or send a Signal-Based notification routed by label to the right connector and preset.' url: https://coralogix.com/docs/user-guides/alerting/configure-notifications/settings/ product: alerts feature: Alert Notifications feature_id: alert-notifications feature_identifier: alerts/alert-notifications last_updated: '2026-11-10' --- # Notification settings The Response step of the [alert creation wizard](https://coralogix.com/docs/user-guides/alerting/configuring-alert-definition.md#step-2-response) is where you decide what an alert is for. Think of notifications as operational outcomes (a Case that someone owns and resolves) rather than raw webhook fan-out. ## What the step contains The alert's notification step stacks several cards, and this page covers the middle three. The others are documented where the feature lives. | Card | What it does | | --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Case settings** | **Auto-resolve Case when the alert resolves**. See [Case settings](https://coralogix.com/docs/user-guides/alerting/define-alert-details.md#case-settings). | | **Enable notifications for this alert** | Turns the rest of the step on or off. | | **Notify on** | Cases or Alerts. Covered below. | | **Routing** | The routing labels that match a router. Covered below. | | **Custom notifications** | A destination set on the alert itself. Covered below. | | **Enrichment** | Runs a DataPrime query when the alert triggers and attaches the results to the notification. See [Enriching notifications](https://coralogix.com/docs/user-guides/notification-center/enrichment.md). | The panel beside the step previews which routers match the labels you have selected, and reports **No matching routers** when none do. ## Pick what triggers the notification The **Notify on** card offers two options. * **Cases** (badged **Recommended**): opens a [Case](https://coralogix.com/docs/user-guides/cases/overview.md) when the alert fires, and notifies on that Case's life rather than on each firing. Status changes, acknowledgements, assignments and resolution all reach the destination, and the Case stays in step with PagerDuty, ServiceNow and Slack in both directions. The sequence is: the alert fires, a Case opens and tracks the response, and notifications follow it. Most teams should start here. * **Alerts**: notifies each time the alert triggers, carrying alert data with no lifecycle updates. Use this for a thin, fire-and-forget signal, for example broadcasting to a chat channel, paging on threshold or forecast triggers, or driving custom webhooks. It offers two tabs, **Destinations** and **Webhooks**, the second holding the legacy outbound webhooks. ## Route the notification Coralogix matches notifications to routers by routing label rather than by a destination set on the alert. Add one or more **routing labels** (typically `Team`, `service`, or `environment`); the router whose ownership rules match delivers to its configured connector and preset. A single alert can then reach different destinations as ownership changes, without editing the alert. For the **Service** label, pick an existing service from the [Service Catalog](https://coralogix.com/docs/user-guides/apm/features/service-catalog.md) (tagged **Catalog**) so the alert and its Case attach to the correct APM service, instead of typing a name that a typo could mismatch. Free text still works (tagged **Custom**) for a service that is not in the catalog yet. If no router matches the labels you select, the wizard shows **No matching routers**. For the full request-to-destination chain, see [How notifications flow](https://coralogix.com/docs/user-guides/notification-center/core-concepts.md); to author a router, see [Routing rules](https://coralogix.com/docs/user-guides/notification-center/routing/define-routing-rule.md). Notifications are not deduplicated Coralogix delivers every path that matches and does not reconcile them, so two paths reaching the same connector and preset notify that destination twice rather than collapsing into one message. This happens in two ways: * More than one router matches the alert's labels, and they share a connector and preset. * A custom notification points at a connector and preset the alert's labels already reach. Before adding a routing label or a custom notification, check where the alert already delivers. ### Matched and potential routers The wizard lists the routers your labels reach, and splits them into two groups. A router matched on a fixed label value is listed as a match: every notification from this alert reaches it. A router matched through a **dynamic** label is listed under **Potential routers**. A dynamic label stands for every value in its category rather than one value, so the match depends on what the alert carries when it triggers. A router in this group delivers only when the alert triggers with that router's exact value. Hover a potential router to see which value it waits for, and which routers are reached through a dynamic label's fallback value instead. Treat the potential group as a list of routers that *could* receive this alert, not a list that will. An alert whose dynamic label never resolves to a listed value notifies none of them. ### Routers or custom notifications Start with a router. Most alerts need nothing else. A router delivers on ownership: you label the alert with its **Team**, **service**, or **environment**, and the router that owns that scope decides where the notification goes. Ownership changes in one place, and every alert that carries the label follows it. **Custom notifications** cover the case a router cannot: this one alert has to reach somewhere specific, regardless of who owns it. You set the destination on the alert itself rather than on an ownership rule. The two work together. Coralogix delivers an alert's custom notifications **as well as** whatever its routing labels match, so adding one leaves the router firing as before, and a destination both paths reach is notified twice. | | Router | Custom notification | | ---------------------- | ---------------------------------------------- | --------------------------------------- | | Set on | An ownership rule, matched by label | The alert itself | | Scope | Every alert carrying the label | This alert only | | Changing where it goes | Edit the router once | Edit each alert | | Use it for | Ownership-level delivery, which is most alerts | A destination that belongs to one alert | Reach for a custom notification when the destination is a property of the alert rather than of the team that owns it: a single alert that has to page a specific vendor channel, or one that feeds a tool nobody else uses. For anything that follows a team, a service, or an environment, use a router. ### Add a custom notification **Custom notifications** sits below **Routing** in the alert's notification step, and is available on alerts that open a Case. 1. In the alert's notification step, with **Cases** selected under **Notify on**, turn on **Custom notifications**. 2. Select **Add destination**. Slack, PagerDuty, and email are the destinations the empty state names. 3. Pick the **Connector** and the **Preset** that formats the message. Any connector that supports Cases can be typed in by name. 4. Leave **Notify for all trigger types** on to notify this destination on every case event, including trigger types added in future. 5. To narrow it, turn that off and select the events you want: | | | | | ---------------- | ------------ | ------------------- | | Activated | Acknowledged | Unacknowledged | | Resolved | Closed | Priority changed | | Assignee changed | KPI breached | Olly analysis ready | | Reactivated | | | 6. Repeat for any other destination. An alert can carry up to 10. Each destination keeps its own triggers, so one can notify on everything while another fires only when a case is activated. See [Notification triggers](https://coralogix.com/docs/user-guides/notification-center/entity-types/cases.md#notification-triggers) for what each event means. ## Tune cadence Cadence applies when **Notify on** is set to **Alerts**. An alert that opens a Case notifies on the Case's lifecycle instead, so there is nothing to tune here. * **Notify every**: how often a re-fire notification is sent while the condition stays true, for example every 10 minutes. * **Notify when resolved**: turn on a follow-up notification when the condition clears. Resolution is automatic on the next evaluation cycle; resolving manually from the Incidents screen does not emit a notification. Note Terraform and API users: verify the `notifyOn` field. Setting it to `triggered_only` suppresses resolved notifications even if the toggle appears on in the UI. See [Troubleshoot alerting](https://coralogix.com/docs/user-guides/alerting/troubleshooting.md#alert-created-via-api-or-terraform-does-not-behave-as-expected). ## Case granularity When **Group by** is set, the **Case settings** in the wizard's Details step control whether matching combinations open a **Combined case** or **Separate cases**. See [Define alert details](https://coralogix.com/docs/user-guides/alerting/define-alert-details.md#case-settings). Note The number of **Group by** permutations is limited to 1000. When more exist, only the first 1000 are tracked. ## Related resources [Notification Center](https://coralogix.com/docs/user-guides/notification-center/introduction.md)[Routing rules](https://coralogix.com/docs/user-guides/notification-center/routing/define-routing-rule.md)[Cases](https://coralogix.com/docs/user-guides/cases/overview.md) ## Next steps Learn about alerts as a notification source type in [Alerts as a notification source type](https://coralogix.com/docs/user-guides/alerting/configure-notifications/source-type-schema.md).