The Notification step of the [alert creation wizard](https://coralogix.com/docs/user-guides/alerting/configuring-alert-definition/#step-3-notification) 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.

## Pick what triggers the notification

- **Cases, Incident Management** (recommended): opens a [Case](https://coralogix.com/docs/user-guides/cases/overview/index.md) when the alert fires. Cases unify related alerts into one operational incident with bi-directional ITSM sync, lifecycle tracking, ownership, and SLA management. Most teams should start here.
- **Alerts, Signal-Based**: sends a per-alert notification. 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. Legacy outbound webhooks live inside this option as **Custom notifications**.

## Route the notification

Coralogix matches notifications to routers by routing label, not by hard-coded destinations. 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/index.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/index.md); to author a router, see [Routing rules](https://coralogix.com/docs/user-guides/notification-center/routing/define-routing-rule/index.md).

## Tune cadence

- **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/#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/#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/) [Routing rules](https://coralogix.com/docs/user-guides/notification-center/routing/define-routing-rule/) [Cases](https://coralogix.com/docs/user-guides/cases/overview/)

## 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/index.md).