Skip to main content
Version: 0.17

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 00:00-23:59 UTC (all day).

  • 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). The interval is configurable.

Persistent operational notifications​

From Core 0.17.0, repeated delivery failures and failed auto-sync runs appear in the dashboard bell as persistent operational incidents. Degraded delivery is a warning; blocked delivery and auto-sync failures reaching the critical threshold are critical. Marking a notification read changes its unread state without resolving the failure. Successful recovery resolves the incident.

Check Control Center for the affected alert, or open the failing auto-sync configuration, and repair its channel or credentials. Critical incidents can escalate by email to eligible token owners and workspace managers/administrators. Escalation is capped per workspace in a rolling 24-hour window, and email-channel failures do not escalate through the same failing channel. See Operational incident tuning for the thresholds, cap, worker settings, and SMTP requirement.

Channels​

Choose which channels to enable and where to deliver notifications:

  • Email: Recipients come from the selected contact groups.
  • Webhooks: 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: Recipients come from workspace contacts selected in the assigned contact groups. Requires Twilio configuration at the deployment level. See Contact groups & channels and WhatsApp templates setup.

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

Control Center: eligibility and delivery​

Open Control Center from the dashboard navigation menu, then Workspace alerting:

  • Eligibility explains whether an asset should generate an alert now, based on its effective thresholds and contact groups.
  • Queue shows queued deliveries, deferrals and retries.
  • Activity shows recent alert lifecycle events across the workspace.

Workspace managers and admins can use these views. Viewers can inspect Alerting and alert history on an asset they can read. A due asset or queue entry is not proof of delivery: check its delivery history and the recipient's inbox. For a complete setup check, follow First asset and alert check.

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.

Activity and delivery counts​

Usage views show workspace, member and asset counts, plus successful email, WhatsApp and webhook sends. Monthly delivery counts reset at the start of the UTC calendar month. Organization totals cover the workspaces owned by that admin; workspace totals cover the selected workspace.

Use these counts to spot a change in notification volume. Use the queue and delivery history to diagnose failed attempts; a monthly counter cannot explain an individual failure.