Skip to main content

Alert delivery and history

A queued alert still needs to pass delivery checks. Use this guide to choose when it can be sent and to investigate a missing notification. Set reminder days in Expiry reminders and thresholds.

Workspace delivery window​

Configure when alerts and weekly digests can be delivered across all channels (email, webhooks, WhatsApp). Alerts and digests are sent only during this delivery window. Alerts outside the window are deferred until the next window opens; the Monday weekly-digest cron is skipped (not deferred) if it falls outside the window. Defaults to 07:00-18:00 UTC.

  • Start/end time: HH:mm format (for example 08:00, 18:00)
  • Timezone: select from 40+ IANA timezones (for example Europe/Zurich, America/New_York)
  • Applies to: all alert channels (email, webhooks, WhatsApp)
  • Validation: strict HH:mm format enforced; invalid values are rejected
  • Midnight wrapping: if start > end (for example 22:00 to 06:00), the window wraps overnight
  • Deferral: alerts outside the window are retried about 3 hours later by default (DELIVERY_WINDOW_DEFERRAL_MS)

Persistent operational notifications​

Repeated delivery failures appear in the dashboard bell as persistent operational incidents. Degraded delivery is a warning; blocked delivery is critical. Opening or marking a notification read clears its unread state without resolving the failure. Successful redelivery resolves the incident. Check Control Center for the affected alert and repair its recipient or channel configuration.

Critical incidents can also escalate by email to eligible token owners and workspace managers/administrators. Escalation has a workspace cap in a rolling 24-hour window, and an email-channel failure does not send an escalation through the same failing channel. Cloud operates these thresholds and SMTP settings; ordinary expiry reminders keep their own delivery policy. Cloud does not provide auto-sync incidents.

Channels​

Choose which channels to enable and where to deliver notifications:

  • Email: available on all plans. Recipients come from the selected contact groups.
  • Webhooks: available on Pro and Team. Create and verify named webhooks for Slack, Microsoft Teams, Discord, PagerDuty, or generic HTTPS endpoints; contact groups reference one or many webhooks to route alerts. Payload formats and setup are covered in Contact groups & channels.
  • WhatsApp: available on all plans. Recipients come from workspace contacts selected in the assigned contact groups. WhatsApp is hosted; you do not configure a provider. See Contact groups & channels.

Delivery visibility: successes and failures appear in the alert queue; failed webhooks can be retried from the queue view.

Control Center: eligibility vs delivery​

Open Control Center from the dashboard navigation menu. It includes Workspace alerting with three tabs:

  • Queue: deliveries already queued. This is delivery: what happened after an alert was queued, including the delivery window, retries, and plan limits.
  • Eligibility: whether each asset should generate an alert now. Workspace-wide counts (Outside threshold, Due, Suppressed) are independent of the paginated asset table. Eligibility unions every assigned contact group's thresholds and channels, matching discovery.
  • Activity: newest alert lifecycle events across workspace assets (threshold, queue, delivery, retry).

Workspace managers and admins see Control Center alerting. Viewers still see Alerting and alert history on a token or certificate they can read: current eligibility, upcoming thresholds, and the per-asset timeline.

Eligibility reasons that are not delivery failures include:

  • The asset was already expired when imported, and no post-expiry (negative) threshold is configured
  • The asset is expired, and no post-expiry threshold is configured
  • Import catch-up suppressed a threshold that had already passed
  • Retired certificates (expiry alerts stay quiet; see Certificates)
  • The threshold is reached, but assigned contact groups have no eligible recipients or channels

Token and certificate detail Alerting and alert history uses the same split. Current eligibility and future scheduling live on the token's alert_state snapshot; the timeline is history and is not used to reconstruct current status.

API fields and endpoints

If a notification is missing​

  1. Check Eligibility: the asset must be due, and its matching contact groups must have recipients and enabled channels.
  2. Check Queue: a closed delivery window defers the alert; a retry is still pending work.
  3. Read the asset's delivery history and any channel error. Failed webhooks can be retried from the queue.
  4. Confirm receipt at the destination. A due asset or queue entry alone does not prove delivery.

Successful sends consume the plan's monthly delivery allowance. Check Usage & limits and Plan limits when a delivery is blocked by the plan.