Routing DNS Alerts to Slack, Discord, or a Webhook Instead of Just Email

An email alert is easy to set up and easy to miss. It works well for one person watching one domain, and it works progressively less well as more people need to see the same alerts, since it depends on everyone actually checking the same inbox, or on someone manually forwarding things along. Team Notifications exists for the point where email alone stops being enough.

The four channel types

Email is the default and requires no setup beyond an address. It's verified before use, and it's the only channel type that supports unsubscribing directly, since it's the one channel where an individual recipient, rather than a shared team destination, is the most common case.

Slack and Discord connect through OAuth, a one-click authorization rather than pasting in a webhook URL by hand. Once connected, alerts post directly into whichever channel or server you authorized during setup.

Webhook sends a POST request to any URL you provide, with no OAuth flow involved. This is the flexible option: point it at PagerDuty, a custom internal tool, an automation platform, or anything else that can accept an incoming HTTP request, and DNS change alerts become an input to whatever system you already use for the rest of your team's alerting.

Why the distinction between Slack/Discord and webhooks matters

Slack and Discord are destinations with a specific, known shape, a channel or server you've already authorized, and OAuth means you never have to think about the URL or credentials involved. A webhook is a blank slate: any URL that accepts a POST is a valid destination, which makes it the right choice for anything that isn't Slack or Discord specifically, whether that's a paging system, a ticketing tool, or a script you wrote yourself that does something with the payload.

Why email still has a place

For a solo user or a small team that already lives in a shared inbox, email is genuinely sufficient, and it's the only channel that doesn't require connecting anything. It also remains useful as a fallback destination even after a team sets up Slack or a webhook, since it doesn't depend on a third-party service or an internal endpoint staying reachable to actually deliver.

Choosing where alerts should actually go

The right destination is wherever your team already looks when something's wrong, not wherever seems most technically capable. A team that lives in Slack gets more value from a Slack alert landing in an already-watched channel than from a webhook feeding a dashboard nobody has open. A team running its own incident-response tooling gets more value from a webhook feeding directly into that system than from an alert that has to be manually correlated with everything else. There's no single right channel, only the one that matches how your team actually notices things.

Setting one up

Each channel type is added per domain or at the account level, and multiple channels can run at once, an email address and a Slack channel receiving the same alerts isn't a conflict, it's a reasonable way to cover both a fallback and a team's primary point of attention at the same time. A channel that's no longer useful, an old Slack workspace, a decommissioned webhook endpoint, is worth removing rather than leaving in place collecting alerts nobody's acting on.