Migrate from outbound webhooks
Move legacy alert webhooks onto the Notification Center model, built around connectors, presets, and Case-based routing. The same pattern applies to every connector type (Slack, Microsoft Teams, PagerDuty, Opsgenie, Email, ServiceNow, and Generic HTTPS). Slack and Microsoft Teams appear as worked examples throughout; swap in your platform's connector and the steps are identical.
Why migrate now
Microsoft deprecated the legacy Office 365 Teams webhooks: since April 30, 2026 they return 401 Unauthorized and no longer deliver notifications. More broadly, a legacy webhook wires a destination URL directly onto each alert, which is brittle and easy to leave silent. Notification Center replaces that with reusable connectors and label-based routing, so you change one router instead of every alert.
What is a Case?
With Notification Center, a notification arrives as a Case, not a one-off message. A Case has a lifecycle: it opens when an alert fires, then moves through assigned, acknowledged, resolved, and closed as your team works it. Routing sends the Case to a destination, and later lifecycle updates follow it there. See Cases overview.
How routing works
A legacy webhook wires a destination URL directly onto each alert definition. Notification Center instead labels the alert and lets a router send the resulting Case to a connector through a preset. This decouples what fires from where it goes, so you can re-route or add destinations without editing every alert.
| Legacy webhook | Notification Center Cases | |
|---|---|---|
| Destination | Webhook URL wired per alert | Connector, reusable across alerts |
| Payload | Fixed webhook body | Preset (system preset recommended; custom via Tera) |
| Targeting | Per-alert webhook assignment | Router matches a routing label (recommended: routing.team) |
| Change management | Edit every alert | Edit one router or one label |
Connector mapping
Each legacy webhook maps to an equivalent connector; anything without a native connector can use the Generic HTTPS connector.
| Legacy webhook | Notification Center connector |
|---|---|
| Slack | Slack connector |
| Microsoft Teams | Microsoft Teams connector |
| PagerDuty | PagerDuty connector |
| Email connector | |
| Generic / HTTPS | Generic (HTTPS) connector |
Before you start
- Permissions: Notification Center admin rights (create connectors and routers, edit alert definitions and labels).
- Connector prerequisites:
- Slack: the Coralogix Slack app installed on your workspace.
- Microsoft Teams: the Coralogix app installed in your tenant and added to each team and channel you want to notify. See Install and set up Microsoft Teams.
- Other platforms: the destination ready (PagerDuty service, email inbox, HTTPS endpoint). If a connector type is not available yet because authorization is not enabled, migrate an available type first and return to it.
- Know your inventory: note which alert definitions point at each legacy webhook, so you know what to re-point once the connector exists.
- Pick your label key: decide the routing label to organize around. Recommended:
team, applied as the routing labelrouting.team(routing labels carry arouting.prefix). It is clear, scalable, and matches Coralogix best practice.
Migration at a glance
- Inventory legacy webhooks and the alerts pointing at each.
- Create the connector and test the connection.
- Select a preset (system preset recommended).
- Build a router with a team-based routing rule.
- Label the relevant alert definitions with the routing label.
- Send a test and verify it lands at the right destination.
- Decide what to do with the old webhook (keep both, or delete).
- Run a coverage check so no alert is left silent.
Step by step
1. Install the platform app first
Every connector needs its platform app installed and authorized before you can create the connector.
- Slack: install the Coralogix Slack app on your workspace and authorize it.
- Microsoft Teams: a Teams admin installs the Coralogix Teams app in your tenant, adds it to each team (via the General channel), then you set up the integration in Coralogix. See Install and set up Microsoft Teams. The Teams connector is in private beta; request access and the app package from your TAM or Support.
- Other platforms: authorize or enable the connector type for your workspace.
2. Inventory your legacy webhooks
List each legacy webhook and note how many alert definitions reference it. Migrate one webhook at a time to keep the blast radius small and verification easy.
3. Create the connector
With the app installed, create a connector for the destination platform and test the connection before wiring anything to it. Mirror the source in the name so the mapping stays obvious, for example Slack - payments-alerts or Teams - payments-alerts.
4. Select a preset
The system preset is the safe default: it follows best practices and guarantees payload accuracy. Build a custom preset (dynamic Tera expressions) only if you have specific formatting or webhook-body requirements, common for Generic HTTPS connectors.
5. Build the router and routing rule
Create a router with a label matcher on your routing label, routing.team (in the UI, select Team). Routing-label matching decides which routers activate; the router's rules then decide where each case goes. These are two separate things, so keep them distinct:
- Everyone gets the same notification: a single rule with no condition.
- Different teams or scenarios route differently: add multiple rules with match criteria, or a separate router per label value.
Point each rule at the connector and preset from the previous steps.
6. Label your alert definitions
This step connects an alert to the router: the router matches on the alert's routing label. Apply the routing label you keyed the router on (for example routing.team : payments) to every alert definition that used the webhook. Routing labels carry a routing. prefix, so add it when you type the label manually; the routing-label selector adds the prefix for you.
- UI, single alert: open the alert definition, then Labels, add
routing.team : payments, then Save. - UI, bulk: in the alerts list, filter or multi-select the alerts that used the webhook, then Edit labels, add the label, and apply to all.
- Terraform or GitOps: add the label to the alert resource and commit, so existing and new alerts stay covered:
resource "coralogix_alert" "payments_5xx" {
name = "Payments 5xx spike"
# ...
labels = {
"routing.team" = "payments"
}
}
7. Send a test and verify
Fire a test notification through the new route and confirm it arrives at the intended destination, for example the Case posts to your Slack or Teams channel.
8. Decide what to do with the old webhook
| Option | Pros | Cons |
|---|---|---|
| Keep both running (verify first, delete later) | No notification gap; easy rollback | Duplicate alerts; dual-system upkeep |
| Delete the old webhook now | No duplicates; clean cutover | A gap until you notice if the new routing is misconfigured |
Recommended: keep the legacy webhook active until you confirm the new route in a live incident or test, then delete it. Do not leave dual systems running indefinitely.
Example: Payments team, Slack
Scenario: the Payments team has a legacy Slack webhook payments-webhook wired to 12 alert definitions, posting to #payments-alerts.
| Step | Action | Result |
|---|---|---|
| Inventory | Find payments-webhook and its 12 alerts | Know your blast radius |
| Connector | Create Slack connector Slack - payments-alerts, authorize, select #payments-alerts, run test | Reusable, verified destination |
| Preset | Keep the system preset | Correct payload |
| Router | Router Payments with a label matcher routing.team : payments (or Team > payments in the UI), plus a rule with no condition, to the connector and system preset | Routing in one place |
| Label | Bulk-select the 12 alerts, add routing.team : payments | Alerts match the router |
| Test | Send a test notification | Message lands in #payments-alerts |
| Old webhook | Keep for one cycle, confirm parity, then delete | Clean cutover, no gap |
| Coverage | Confirm no Payments alert is unlabeled | No silent alerts |
Need to add PagerDuty later? Add a second target to the same rule, with zero alert edits.
Example: Infra team, Microsoft Teams
Scenario: the Infra team's legacy Teams webhook stopped working (Microsoft 401). It posted to the Infra Alerts channel in the SRE team and was wired to 15 alert definitions.
Teams adds two upfront steps that Slack does not: installing the Coralogix Teams app and creating the integration, both of which need a Microsoft Teams admin. See Install and set up Microsoft Teams.
| Step | Action | Result |
|---|---|---|
| Inventory | Find the Teams webhook and its 15 alerts | Know your blast radius |
| Install app | Teams admin installs the app and adds it to the SRE team | App available in Teams |
| Integration | Coralogix Integrations > Microsoft Teams, consent, then Authorize (admin consents) | Tenant connected |
| Connector | Notification Center Connectors > Microsoft Teams, pick the integration, paste the Infra Alerts channel link | Reusable destination |
| Preset | Keep the system preset | Correct payload |
| Router | Router Infra with a label matcher routing.team : infra (or Team > infra in the UI), plus a rule with no condition, to the Teams connector and system preset | Routing in one place |
| Label | Bulk-select the 15 alerts, add routing.team : infra | Alerts match the router |
| Test | Send a test notification | Case posts to Infra Alerts |
| Old webhook | Already stopped working (Microsoft 401); delete it once the new route is confirmed | No dual system |
| Coverage | Confirm no Infra alert is unlabeled | No silent alerts |
Targeting a private channel? Add the app to that channel directly (Manage channel > Coralogix > Add).
Do not leave alerts silent
Before you consider a webhook fully migrated, check for alert definitions with no notification destination, alerts that would fire silently. Review the alerts that referenced the retired webhook, and label any that never received the routing label. This sweep is what prevents a critical alert from going nowhere after cutover.
Migrate Alert-type routing rules
If you also have Alert-type routing rules in Notification Center, not just webhooks, those move to Cases-type rules. Conditions can be translated to Cases syntax, but treat any translated condition as recommended, not guaranteed: review and edit it before you commit, or use a trigger-always (true) rule if you just want everything to route. Handle this once your webhook migrations are stable.
Verify it worked
- The test notification arrived at the correct destination.
- The migrated alerts carry the right routing label.
- The router rule matches those labels and points at the right connector and preset.
- A coverage check shows no migrated alert left without a destination.
- If you deleted it, the old webhook is gone and nothing else depended on it.
Troubleshooting
- Notifications are not arriving. Check, in order: the alert has the routing label, a router rule matches it, the rule points at the right connector, and the connector's test succeeds.
- They went to the wrong place. Recheck the connector's target destination, then use Send test to confirm before relying on the route.
- Some alerts stopped notifying after deleting the webhook. Those alerts were probably never labeled. Run the coverage check and label them.
- A migrated rule never fires. The translated Cases condition may be invalid. Open the rule, review the condition, and fix it, or switch off the condition so the rule always matches.
- A connector type is not available. Some connectors depend on your workspace's authorization being enabled. Migrate an available type first and return once it is enabled.