Alert History
The History page provides a complete log of every notification dispatched by the SetGet alert system. Every email, SMS, and in-app notification is recorded with its delivery status, recipient, template, trigger source, and timestamp. Use the history to verify that alerts are being delivered correctly, diagnose delivery failures, and audit notification activity.
Alert history is accessible from Workspace Settings > Reminders > History.
The history log table
The history page displays a paginated table of notification sends with the following columns:
| Column | Description | Example |
|---|---|---|
| Channel | The notification channel used | email, sms, in_app |
| Recipient | Display name and email/phone of the recipient | Jane Smith (jane@example.com) |
| Template | The email template used to format the notification | State Change |
| Trigger | The trigger or state mapping that caused the notification | "Any to In Review" or "state_changed trigger #3" |
| Entity | The work item or entity that the notification relates to | ENG-142: Fix login redirect |
| Status | Delivery status of the notification | sent, pending, failed |
| Timestamp | Date and time when the notification was dispatched | 2026-03-29 14:30:22 UTC |
Rows are sorted by timestamp in descending order (most recent first).
Delivery status types
Each notification send has one of three status values:
| Status | Badge color | Description |
|---|---|---|
| Pending | Yellow | The notification has been queued but not yet delivered. This is a transient state. |
| Sent | Green | The notification was successfully delivered to the channel provider (SMTP server, Twilio, or in-app notification service). |
| Failed | Red | The notification could not be delivered. An error message is available in the detail view. |
Status lifecycle
Event occurs → Trigger evaluates → Notification queued (Pending)
→ Delivery succeeds → Sent
→ Delivery fails → Failed (error recorded)Most notifications transition from Pending to Sent within seconds. If a notification remains in Pending status for more than a few minutes, there may be a queue processing issue.
TIP
A "Sent" status means the notification was accepted by the delivery provider (e.g., SMTP server or Twilio API). It does not guarantee final delivery to the recipient's inbox or phone. For email, the message may still be filtered by spam rules. For SMS, carrier-level delivery issues may occur.
Viewing send details
Click on any row in the history table to open the detail panel. The detail view includes:
| Field | Description |
|---|---|
| Full recipient info | Name, email address, phone number (for SMS) |
| Template name | The template used, with a link to the template preview |
| Template variables | The actual variable values used in this specific send |
| Trigger details | Which trigger or state mapping generated this notification |
| Entity details | Work item ID, title, project, and a link to the item |
| Channel | The delivery channel |
| Status | Current delivery status |
| Error message | For failed sends, the specific error returned by the provider |
| Timestamps | Queued time, sent time (or failure time) |
Error messages for failed deliveries
When a notification fails, the system records the error message from the delivery provider. Common error messages include:
Email delivery errors
| Error message | Cause | Resolution |
|---|---|---|
SMTP connection refused | The SMTP server is unreachable | Verify SMTP host and port in instance settings |
SMTP authentication failed | Invalid SMTP credentials | Re-enter SMTP username and password |
Recipient address rejected | The recipient's email address is invalid or the mailbox does not exist | Verify the user's email address |
Message size exceeds limit | The email body is too large | Contact support; this is unusual for notification emails |
TLS handshake failed | SSL/TLS configuration mismatch | Verify SMTP encryption settings (STARTTLS vs implicit TLS) |
Connection timeout | Network issue or SMTP server overloaded | Retry later; check network connectivity |
SMS delivery errors
| Error message | Cause | Resolution |
|---|---|---|
Invalid phone number format | The recipient's phone number is not in E.164 format | Update the phone number in the user's profile |
Twilio authentication error | Invalid Account SID or Auth Token | Re-enter Twilio credentials in SMS settings |
Twilio insufficient funds | Twilio account balance is zero | Add funds to your Twilio account |
Webhook returned 4xx | Your generic webhook endpoint rejected the request | Check your webhook endpoint logs |
Webhook returned 5xx | Your generic webhook endpoint encountered a server error | Check your webhook endpoint health |
Webhook connection refused | The webhook URL is unreachable | Verify the webhook URL and network connectivity |
Unverified number (trial) | Twilio trial account cannot send to unverified numbers | Verify the number in Twilio or upgrade to a paid account |
In-app delivery errors
In-app notifications rarely fail. When they do, the error is typically:
| Error message | Cause | Resolution |
|---|---|---|
User not found | The recipient user was deleted after the notification was queued | No action needed; the user no longer exists |
Internal dispatch error | Unexpected server error | Check server logs for details |
Filtering the history
The history page provides filters to narrow the log view:
Filter by channel
Select one or more channels to display:
| Filter value | Shows |
|---|---|
| All | All notification sends across all channels |
| Only email notifications | |
| SMS | Only SMS notifications |
| In-app | Only in-app notifications |
Filter by status
| Filter value | Shows |
|---|---|
| All | All statuses |
| Pending | Only queued notifications awaiting delivery |
| Sent | Only successfully delivered notifications |
| Failed | Only failed notifications (useful for troubleshooting) |
Filter by date range
Select a start date and end date to limit the log to a specific time window. This is useful for investigating delivery issues during a particular period or auditing notification volume over time.
Combined filters
Filters can be combined. For example, filtering by Channel: SMS and Status: Failed shows only failed SMS deliveries, which is the most common troubleshooting scenario.
Pagination
The history log is paginated to handle large volumes of notification data:
- Default page size: 50 entries per page
- Navigate between pages using the pagination controls at the bottom of the table
- The total count of matching records is displayed above the table
For workspaces with high notification volume, use date range filters to narrow the result set before browsing.
Exporting history
To export the notification history for external analysis or reporting:
- Apply any desired filters (channel, status, date range).
- Click Export above the table.
- Select the export format (CSV).
- The exported file includes all columns from the history table for the filtered result set.
The export respects your current filters. To export all history, clear all filters before exporting.
TIP
Regular history exports can help identify patterns in delivery failures and track notification volume trends over time. Consider scheduling monthly exports for your records.
Troubleshooting failed sends
When you notice failed sends in the history, follow this systematic approach:
Step 1: Identify the pattern
Filter the history by Status: Failed and look for patterns:
- Are failures concentrated on one channel (email vs. SMS)?
- Are failures affecting one recipient or many?
- Did failures start at a specific time?
Step 2: Check the error message
Click on a failed send to read the error message. The error usually points directly to the cause (authentication failure, invalid address, network issue, etc.).
Step 3: Verify configuration
Based on the error:
| Channel | Configuration to check |
|---|---|
| Instance SMTP settings (host, port, credentials, encryption) | |
| SMS | Workspace SMS provider settings (see SMS configuration) |
| In-app | Server health and process status |
Step 4: Send a test
After fixing the configuration:
- Go to Templates and send a test notification through the affected channel.
- Verify the test appears in History with a "Sent" status.
- Check that the test was actually received by the recipient.
Step 5: Monitor
After resolving the issue, monitor the History page for the next few hours to confirm that new notifications are being delivered successfully.
Data retention
Notification history records are retained for the lifetime of the workspace. There is no automatic purge. For workspaces with very high notification volume, the history collection grows over time but is indexed for efficient querying.
WARNING
History records include recipient contact information (email addresses and phone numbers). Ensure that access to the History page is restricted to workspace administrators who are authorized to view this data.
Related pages
- Alerts overview --- Introduction to the alert system
- Triggers --- Configure event-based notification triggers
- Templates --- Email template catalog and variable reference
- SMS configuration --- Set up SMS delivery providers
- Notification preferences --- Per-user channel configuration
- Best practices --- Design an effective notification strategy
- Troubleshooting --- General troubleshooting guide