Domainyze sends eleven distinct alert types. This page lists all of them: what fires each one, which domains it applies to, and the webhook event name it carries so you can route on it in code.
Every alert type can be delivered to any channel you have configured, and every destination has its own alert-type filter. The same event can email you, post to #on-call in Slack and hit your webhook endpoint, or go to only one of the three.
Domain lifecycle alerts
Domain is now available
Webhook event: domain.available
The domain has left the registry and can be registered by anyone. This is the highest-severity alert in the product, and the only one promoted to the priority delivery queue, because the gap between a good domain dropping and somebody else taking it is measured in seconds.
It fires once per drop. If the domain is registered again and later drops a second time, that is a new event and the alert arms itself again.
Applies to: watchlist and portfolio domains.
Lifecycle stage changed
Webhook event: domain.status_changed (the payload carries old_stage and new_stage)
The domain moved to a new lifecycle stage: the plain-language answer to where a name sits on the road to being registrable. The stages are active, expiring soon, grace, redemption, pending delete, available, and the two ways a watch ends, reclaimed (the owner renewed, so stop waiting) and taken (someone else registered it), plus the off-path auction, blocked and unknown.
Stage changes are the earliest warning you get, in both directions. On a domain you own, a move into grace usually means a failed renewal or a registrar problem, and you still have time to fix it. On a domain you want, the walk through grace, redemption and pending delete is the countdown to it becoming available.
The stage is derived from the raw registrar status plus the expiry date, so a registrar rewording its status text does not fire a false alert. You choose which stages you want to hear about per domain, in the domain's alert settings.
One stage is special. When a watched name is listed for sale on the resale market instead of dropping, its stage becomes auction, and that stage change is the aftermarket alert: it carries the marketplace, the sale type, the current price, and the deadline, with a link to the listing. It has its own on/off switch per domain and is delivered on a paid plan; every account still sees the stage. Only auction and closeout listings raise it, never a fixed buy-now price. See how aftermarket alerts work.
Applies to: watchlist and portfolio domains. The aftermarket case applies on a paid plan, with the domain's aftermarket alert left on.
Watched domain is about to drop
Webhook event: watchlist.drop_imminent
A name you are watching has an observed drop time approaching, and one of your lead-time windows has arrived. This is the alert that turns a forecast into an action: it tells you the window is open now, at the specific minute, so you can be at the registrar when the name releases.
It fires only once Domainyze has directly observed the name enter pending delete on a TLD whose drop timing it can characterise, so the countdown is anchored to a real observation and not to an estimate. The lead times are a paid feature: Pro is alerted 1 day and 1 hour ahead, Business also gets a final 10-minute warning. Each lead time fires once per drop.
Applies to: watchlist and portfolio domains, on a paid plan.
Domain registration details changed
Webhook event: watchlist.registration_changed
The ownership fingerprint of a name moved: a transfer to a new registrar, a re-registration by a new owner, or a nameserver re-point. On a competitor's name or one you are tracking, this is the signal that something changed hands or changed hosting.
Applies to: watchlist and portfolio domains, on a paid plan.
Domain expires soon
Webhook event: domain.expiry_digest
A domain you own is approaching its expiry date. You choose the reminder days per domain, and set an account-wide default under Settings → Portfolio. The available windows are 90, 30, 7 and 1 day; new accounts default to 30, 7 and 3 days.
Reminders are sent as one daily digest: once a day, every domain that reached a reminder window that day is bundled into a single message per channel (the webhook payload carries domain_count and a domains list), rather than a separate message per domain. Each window is still announced at most once per expiry date. When the domain is renewed and the registry publishes the new date, every window re-arms against it, so next year's reminders are unaffected by this year's.
Applies to: portfolio domains only. A watchlist domain expiring is not a problem you need to fix, it is the outcome you are waiting for, and it is already covered by the status change and availability alerts.
SSL certificate alerts
SSL certificate expires soon
Webhook event: ssl.expiry_digest
The certificate served on the domain is inside its renewal window. Automated certificates are typically 90 days and renew themselves, which is exactly why this alert is worth having: its real job is to tell you the automation did not run.
Like domain expiry, certificate reminders arrive as one daily digest listing every certificate that reached a window that day (the webhook payload carries domain_count and a domains list), and each window is announced at most once per certificate. Renew the certificate and the windows re-arm against the new expiry date, so a successful renewal stops the reminders immediately rather than at the end of a cooldown.
SSL certificate is invalid
Webhook event: ssl.invalid
The certificate is expired, revoked, self-signed, issued for a different hostname, or the TLS handshake failed outright. Visitors are seeing a browser security interstitial right now, so this is treated as critical.
Both SSL alerts apply to: portfolio domains on a paid plan, with SSL monitoring enabled for that domain. Certificates are checked daily.
DNS alerts
DNS changes are split into three alert types, so the events that matter most are not buried in ordinary record churn. Every one is confirmed against a second resolver before it is sent, so a one-off glitch a second resolver does not see is never alerted.
Nameserver delegation changed
Webhook event: dns.delegation_changed
Your NS or SOA records moved: the domain's delegation itself changed. This is the highest-priority DNS alert, because handing a zone to new nameservers hands over everything in it. We check delegation on its own faster lane (as often as hourly on Business), query it against your domain's own authoritative servers rather than a cache, and additionally flag when your live nameservers disagree with the ones your registrar has on record.
Email authentication changed
Webhook event: dns.email_auth_changed
An MX, SPF, DKIM or DMARC record moved. Someone who takes over a zone changes MX to intercept mail and rewrites SPF or DMARC so the interception is not rejected downstream, and both edits surface here. A silently broken DKIM selector is the more ordinary case: nothing looks wrong until deliverability quietly drops off weeks later. Your Mail card also carries an overall posture grade (strong, adequate, weak, absent). See SPF, DKIM & DMARC monitoring.
DNS records changed
Webhook event: dns.records_changed
Any other record was added, removed or changed: website A/AAAA, CAA, verification TXT, and so on. The alert names the exact records that moved, and a value edit is reported as a single changed record with its before and after rather than an unrelated removal and addition.
You can exclude record types you edit routinely, per domain, so a team that changes A records daily still hears about NS and MX. If the same change keeps recurring, the repeats are rolled up rather than re-sent every check.
DNS connectivity failed
Webhook event: dns.connectivity_failed
We could not resolve the domain's DNS at all, repeatedly. This is categorically different from records changing: nothing was edited, the zone is simply not answering. It usually means an expired domain, a nameserver outage, or a registrar hold that has taken the delegation down.
All DNS alerts apply to: portfolio domains on a paid plan, with DNS monitoring enabled for that domain. DNS is checked on a tiered schedule: more often on Business than Pro, with nameservers on a faster lane.
Monitoring health alerts
These two are alerts about the monitoring itself. Without them, a portfolio that has silently stopped being checked looks identical to a portfolio where nothing is wrong, which is the most dangerous state a monitoring product can be in.
Monitoring auto-paused
Webhook event: monitoring.auto_paused
A check type was paused automatically after sustained consecutive failures on one domain. We pause rather than retry forever, because a domain whose DNS has been unreachable for days is not a transient failure, and continuing to hammer it helps nobody.
The alert names the domain and the specific check type that paused, so you know both what stopped and what is still running.
Monitoring recovered
Webhook event: monitoring.recovered
A paused check succeeded again and has resumed on its normal schedule. This is the "you can stop worrying" alert, and it is the lowest-priority thing we send.
Wantlist digest (email only)
Separately from the channel-routed alerts above, a wantlist sends an email-only digest. A wantlist is a saved search over the resale market, and when new listings match your saved filters they collect into one email per wantlist, labelled with the search. It is a summary of a saved search rather than an event on a domain you own, so it is not routed to Slack, Discord, or a webhook, and it carries no webhook event name. If nothing new matched, no email is sent.
Delivery channels
| Channel | Plan | What it looks like |
|---|---|---|
| Free | Full detail, always available on every plan | |
| Webhook | Paid | JSON to any https:// endpoint, HMAC-SHA256 signed |
| Slack | Paid | Block Kit message with a link back to the domain |
| Discord | Paid | Embed, colour-coded by severity |
Each destination carries its own alert-type filter, so routing by severity is a matter of adding a second destination rather than writing any code.