Domainyze delivers every domain alert to one or more destinations. A destination is a single place an alert can land: your inbox, an HTTPS endpoint you control, a Slack channel, or a Discord channel. You can have as many as you like, and every alert fans out to all of the ones that are enabled.
This article is the overview. If you already know which channel you want, jump straight to the step-by-step guide:
- Send domain alerts to Slack
- Send domain alerts to Discord
- Webhook payloads and signature verification
The channels at a glance
| Channel | Plan | What the destination is | Signed | Alert-type filter |
|---|---|---|---|---|
| Free | Your account email address | No | Yes | |
| Webhook | Paid | Any https:// URL you control |
Yes, HMAC-SHA256 | Yes |
| Slack | Paid | A Slack Incoming Webhook URL | No, the URL is the credential | Yes |
| Discord | Paid | A Discord channel webhook URL | No, the URL is the credential | Yes |
Email is free forever. A monitoring product that cannot email you is not a monitoring product, so that line will not move. Every other outbound channel is part of a paid plan.
Where to manage destinations
All delivery settings live in one place: Settings, then the Alerts tab. You will see:
- Your email destination, always listed first, with a single enable/disable switch.
- Every channel you have added, each with its target, its alert-type filter summary, a recent-failure count if there is one, and a Manage button.
- An "Add a channel" picker at the bottom. It stays available after you have added something, because a channel can have more than one destination. Two Slack channels, one for the whole team and one for the on-call rotation, is a normal setup.
Adding a destination
- Go to Settings, then Alerts.
- Under "Add a channel", pick Webhook, Slack or Discord.
- Paste the destination URL. Each channel validates the shape of the URL you paste, so a Discord URL dropped into the Slack field becomes a form error immediately rather than a silent stream of failed deliveries later.
- Optionally add a description. This is only for you, and it is what makes a list of six webhook URLs readable six months from now.
- Choose which alert types this destination should receive, or leave it on "all types".
- Save.
For the generic webhook channel, a signing secret is generated and shown to you exactly once, at the moment you create the destination. Copy it then. It is stored hashed on our side and cannot be shown again; if you lose it, use Rotate secret in the Manage panel to issue a new one.
Choosing which alerts go where
Every destination has its own alert-type filter, which is what makes multiple destinations useful. A common arrangement:
- Slack, critical only. Availability and status changes go to the channel your team actually reads.
- Email, everything. The full record, searchable, in one place.
- Webhook, expiry and SSL only. Piped into your own ticketing system so renewals become tracked work rather than a message someone scrolled past.
A destination with no filter set receives every alert type. That is deliberate: a destination created before the filter existed, or by someone who never opens that part of the UI, keeps working exactly as it did.
Testing a destination
Open a destination's Manage panel and press Send test. Domainyze delivers a real, fully-formed alert through the real delivery path, including the signature, and records the result in the delivery log alongside genuine alerts. There is no separate "test mode" that could behave differently from production, because a test that takes a different code path proves nothing about the path that matters.
The delivery log
Each destination keeps a log of its recent deliveries: when we sent it, the alert type, the response status, and whether it succeeded. Two things you can do from there:
- Replay a delivery. Useful when your endpoint was down, or when you have just fixed a bug in your receiver and want the original alert again rather than an approximation of it. A replay re-renders the original alert from the stored envelope, so what you get is byte-for-byte what we sent the first time.
- Diagnose a failure. The log shows the response code and the error we saw, which is usually enough to tell an expired Slack webhook from a firewall rule from a 500 in your own handler.
Retries and automatic disabling
When a delivery fails, we retry with a backoff of roughly 10 seconds, then 1 minute, then 5 minutes, and we keep retrying for up to 6 hours from the original alert. Retries are bounded by time rather than by a fixed number of attempts, so a destination that rate-limits us does not burn through its attempts without ever actually failing.
If your endpoint returns a 429 with a Retry-After header, we honour it. Your endpoint knows when it will be ready better than our backoff schedule does.
After 20 consecutive failed deliveries, a destination is automatically disabled and you are notified. This protects both sides: your endpoint stops being hammered, and your other destinations stop competing with a dead one for delivery capacity. Fix the endpoint, then re-enable the destination from the Alerts tab. The failure counter resets on the first success.
Rate limits
Each destination has its own delivery budget, keyed to the destination rather than to your account, so one misbehaving endpoint cannot slow down your others.
- Webhook: 60 deliveries per minute.
- Slack and Discord: roughly 1 message per second, matching what those platforms ask for.
Security
- Only
https://URLs on standard ports are accepted. - Every outbound request passes through an SSRF guard that resolves the hostname and refuses private, loopback and link-local addresses. A webhook URL pointing at internal infrastructure is rejected rather than delivered.
- Generic webhook payloads are signed with HMAC-SHA256. See Webhook payloads and signature verification.
- Slack and Discord URLs contain their own authentication token in the path, which means the URL is the credential. We store those as secrets and show them masked everywhere after creation. A separate HMAC signature would sign nothing that the URL does not already prove, so we do not send one on those channels.
SMS
SMS is not a native channel today. In the meantime the webhook channel covers it well: point a webhook at Twilio, Zapier or a similar service and have it send the SMS. Because you control the receiver, you also control which alert types are urgent enough to wake someone up.