Alert routing

An alert is useless if it lands where nobody looks.

Domain Trust Watch sends certificate warnings to durable inboxes, watched Slack channels, or signed webhooks depending on urgency and team process.

Read alerting docsWebhook setup

Alert route

Critical warnings are routed

Slack + email

Expiry, validation, and certificate-change events keep the route and delivery attempts attached to the hostname.

SeverityFinal-week expiry
Slack#certificates delivered
WebhookSigned payload ready
Route by workspace, hostname, channel, and severity
Alert routing

Route warnings by workspace, hostname, channel, and severity.

Alert routes show which events go to Slack, email, or signed webhooks before a missed warning becomes a second problem.

01

Match the channel to the deadline

A 30-day expiry reminder and a final-week validation failure should not always go to the same place. Send planned work to durable channels and urgent failures to watched operational paths.

  • Send 30-day and 14-day warnings to shared email.
  • Send 7-day, 3-day, 1-day, expired, and validation failures to Slack.
  • Send automation events to signed webhooks for ticketing or inventory updates.
Severity-to-channel strategy
EventCommon urgencyRecommended route
30-day and 14-day expiryPlanned renewal work.Shared email, renewal queue, or ticket backlog.
7-day and 3-day expiryActive operational risk.Watched Slack channel plus ticketing webhook if used.
1-day or expiredCritical customer-facing risk.Critical Slack route or signed webhook into incident workflow.
Validation failureEndpoint may be rejected by clients.Service or platform channel that owns the failing hostname.
Certificate changeReview after renewal, CA move, CDN change, or unexpected binding.Lower-noise review route unless paired with validation failure.
02

Test before you rely on it

Each channel can be tested from the dashboard. Delivery attempts show success, retries, provider errors when available, and dead-letter status when a destination keeps failing.

  • Confirm a warning was generated.
  • Find stale Slack webhook URLs or inboxes before the next expiry window.
  • Use failed delivery records as channel cleanup work.
03

Choose workspace or monitor-specific routes

Workspace-wide routes are useful for default renewal coverage. Monitor-specific routes are better for checkout, identity, client, API, or CDN hostnames where a different team owns the fix.

  • Use workspace defaults for normal expiry reminders.
  • Override high-risk hostnames when the alert belongs in a different channel.
  • Keep delivery logs attached to the certificate event so routing failures are reviewable.
04

Signed webhooks for internal systems

Customer webhooks are signed with HMAC-SHA256 over timestamp and body. Receivers can reject stale timestamps and mismatched signatures before creating tickets or updating inventory.

  • Forward expiry, validation, and change events to internal tools.
  • Verify signatures before acting on payloads.
  • Use retry logs to distinguish receiver outages from configuration mistakes.
FAQ2 answers

  1. Which alert channels does Domain Trust Watch support?

    Domain Trust Watch supports email channels, Slack incoming webhooks, and signed customer webhooks for certificate events.

  2. Can I see whether a warning was sent?

    Yes. Delivery logs show attempts, retry status, provider errors when available, and dead-letter outcomes for configured channels.

Related4 pagesSlack integrationSend final-week warnings to a watched Slack channel.Explore Slack integration
IntegrationEmail alertsUse shared inboxes for durable renewal reminders.DocsWebhook docsVerify signed payloads before creating internal tickets.PricingPricingChoose a plan with the channels and monitored hostname count you need.
Connect a warning path

Check one hostname, then decide where recurring warnings should go.

Run the checker first. Add monitoring when the result needs repeated checks and alerts in email, Slack, or a webhook.

Run SSL checkerRead alerting docs