# Alerts Table Guide
The Alerts section provides a comprehensive view of all triggered alerts in your system. This is where you can search, filter, and analyze alert activity to understand what alerts have fired, their delivery status, and any issues with alert notifications.
## Accessing the Alerts Table
Navigate to **"Alerts"** in the Logging section to view all triggered alerts. This interface shows you the history of alert activity and the delivery status of notifications.
## Search and Filter Interface
The alerts table includes the same powerful search and filtering capabilities as the logs section.
### Search Bar
Search across all alert fields including:
- Alert rule names
- Alert summaries
- Event types that triggered alerts
- Notification targets (email addresses, phone numbers)
### Time Range Filters
- **Default View**: Shows recent alerts
- **Custom Date Range**: Select specific start and end dates to analyze alert patterns during particular time periods
- **Quick Ranges**: Last 24 hours, 7 days, 30 days, etc.
### Search Status Indicator
The **"Search filters are dirty"** message indicates that you have unsaved filter changes that haven't been applied yet.
## Alerts Table Structure
The alerts table displays triggered alerts with the following columns:
### Rule Column
- **Alert Rule Name**: The name of the alert rule that triggered (e.g., "Failed Login Monitor")
- **Rule Identification**: Helps you identify which monitoring rule detected the condition
### Alert Column
- **Alert Summary**: Description of what triggered the alert
- **Event Information**: Shows the event type and details
- **Examples**:
- `CRITICAL: login_success` - Critical alert for login success events
- `login_success` - Standard alert for login events
- **Severity Indication**: Critical alerts are clearly marked
### Urgency Column
- **Alert Priority**: Shows the urgency level of the alert
- **Critical**: Red text indicating high-priority alerts that were sent immediately
- **Standard**: Normal priority alerts that were batched
- **Visual Indicator**: Color coding helps identify alert severity at a glance
### Status Column
- **Trailonix Processing Status**: Shows Trailonix's internal processing status, not final delivery status
- **Status Types**:
- **sent**: Trailonix has sent the alert to our processors (SMTP2GO for email, Twilio for SMS)
- **suppressed**: Alert was triggered but will not be sent due to suppression rules
- **queued**: Alert is triggered and waiting for the next batch to run
- **Blue Info Icon** (ℹ️): Click to view actual delivery status from external providers (email/SMS delivery success/failure)
- **Important**: "sent" status only means Trailonix submitted the alert to processors - check the status modal for actual delivery confirmation
### Triggered Column
- **Timestamp**: When the alert was first triggered
- **Format**: Date and time format (e.g., `6/6/25, 8:45 AM`)
- **Sortable**: Click column header to sort by trigger time
- **Chronological Order**: Most recent alerts typically appear first
## Alert Status Details
### Status Modal
Click the **blue info icon** (ℹ️) in the Status column to open the "Sent Status" modal, which shows detailed delivery information for each notification target.
**Status Modal Structure:**
- **Target**: Shows the notification destination (email address, phone number)
- **Status**: Delivery status for that specific target
- **Time**: When the notification was processed
### Notification Status Types
The status modal shows delivery results as reported by external processors (SMTP2GO for email, Twilio for SMS). These statuses come directly from the third-party providers and may include various delivery states, failure reasons, or success confirmations.
**Common Status Categories:**
- **Success statuses**: Indicate successful delivery to the recipient
- **Failure statuses**: Show various reasons why delivery was unsuccessful
- **Pending statuses**: Indicate notifications still being processed
- **Unsubscribed statuses**: Show when recipients have opted out
**Status Details:**
The exact status messages and descriptions come directly from the external providers and will vary based on the specific delivery outcome, carrier responses, or email server responses.
**Warning Indicators:**
- **Yellow Warning Triangle** (⚠️): Indicates delivery errors - contains details about what went wrong if error information was received from the external processors
### Understanding Alert Processing vs Delivery
**Trailonix Processing Status (Main Table):**
- **sent**: Trailonix has successfully handed off the alert to external processors
- **queued**: Alert is waiting for the next batch processing cycle
- **suppressed**: Alert triggered but blocked by suppression rules
**Actual Delivery Status (Status Modal):**
- **delivered**: Final confirmation that the notification reached the recipient
- **failed**: External processor could not deliver the notification
- **bounced**: Email was rejected by recipient's server
- **unsubscribed**: Recipient has opted out of notifications
> **🔍 Important Distinction:** The main table shows Trailonix's processing status, while the status modal shows actual delivery results from SMTP2GO (email) and Twilio (SMS). An alert can show "sent" in the main table but still have delivery failures visible in the status modal.
## Alert Analysis Patterns
### Monitoring Alert Effectiveness
1. **Search by rule name** to see how often specific alerts trigger
2. **Check delivery status** to ensure notifications are reaching intended recipients
3. **Look for suppression patterns** to optimize alert frequency
4. **Analyze time patterns** to understand when issues occur most frequently
### Troubleshooting Delivery Issues
1. **Filter by failed status** to identify delivery problems
2. **Check status details** for specific failure reasons
3. **Verify contact information** is current and correct
4. **Review unsubscribe status** for missing notifications
### Alert Performance Analysis
1. **Compare critical vs standard alerts** to ensure appropriate prioritization
2. **Monitor response times** between trigger and delivery
3. **Track alert volume** to identify noisy rules that need adjustment
4. **Analyze suppression effectiveness** to reduce alert fatigue
### Security and Compliance
1. **Track critical security alerts** and their delivery status
2. **Monitor alert rule effectiveness** for compliance requirements
3. **Verify alert delivery** for audit trail purposes
4. **Review alert patterns** for security incident investigation
## Common Alert Scenarios
### Normal Operations
- **Status**: "sent" with successful delivery to all targets
- **Pattern**: Regular but not excessive alert activity
- **Action**: Monitor for trends and patterns
### Delivery Issues
- **Status**: "failed" or partial delivery with warnings
- **Pattern**: Consistent failures to specific targets
- **Action**: Update contact information or troubleshoot delivery
### Over-Alerting
- **Status**: Many "suppressed" alerts
- **Pattern**: Same rule triggering frequently
- **Action**: Adjust alert thresholds or suppression settings
### Under-Alerting
- **Status**: Very few or no alerts despite known issues
- **Pattern**: Missing expected alert activity
- **Action**: Review alert rule configuration and thresholds
## Best Practices for Alert Management
### Regular Monitoring
- **Daily Review**: Check for failed deliveries and critical alerts
- **Weekly Analysis**: Look for patterns and optimization opportunities
- **Monthly Audit**: Review alert effectiveness and update contact information
### Delivery Optimization
- **Verify Contacts**: Ensure all notification targets are current and valid
- **Test Delivery**: Periodically verify that alerts reach intended recipients
- **Monitor Unsubscribes**: Track opt-outs and update notification strategies
- **Backup Notifications**: Use multiple channels for critical alerts
### Alert Tuning
- **Analyze Suppression**: Use suppression data to optimize alert frequency
- **Adjust Thresholds**: Modify alert conditions based on actual trigger patterns
- **Review Criticality**: Ensure critical designation is used appropriately
- **Update Rules**: Keep alert rules current with application changes
## Troubleshooting Common Issues
### "Alerts Not Delivering"
**Possible Causes:**
- Invalid or outdated contact information
- Recipients have unsubscribed
- Email/SMS provider issues
- Network connectivity problems
**Solutions:**
- Check status details for specific failure reasons
- Verify and update contact information
- Re-subscribe users who want to receive alerts
- Test with alternative notification methods
### "Too Many Suppressed Alerts"
**Possible Causes:**
- Alert thresholds set too low
- Suppression periods too short
- Underlying issues causing repeated triggers
**Solutions:**
- Increase alert thresholds or suppression periods
- Investigate and resolve underlying issues
- Consider changing from critical to batch alerts
### "Missing Expected Alerts"
**Possible Causes:**
- Alert rules not configured correctly
- Thresholds set too high
- Event types not matching actual events
- Suppression periods too long
**Solutions:**
- Review alert rule configuration
- Lower thresholds for testing
- Verify event type names match logs exactly
- Adjust suppression settings
### "Inconsistent Delivery"
**Possible Causes:**
- Intermittent network issues
- Email/SMS provider rate limiting
- Recipient server issues
- Contact information changes
**Solutions:**
- Monitor delivery patterns over time
- Use multiple notification channels
- Implement delivery retry mechanisms
- Regularly update contact information
## Integration with Other Features
### Connecting to Logs
- **Investigate Triggers**: Use log data to understand why alerts fired
- **Validate Rules**: Check if alert rules are catching the right events
- **Pattern Analysis**: Compare alert activity with log patterns
### Improving Alert Rules
- **Threshold Optimization**: Use alert frequency data to adjust thresholds
- **Suppression Tuning**: Optimize suppression based on actual trigger patterns
- **Contact Management**: Update notification targets based on delivery success
### Operational Workflows
- **Incident Response**: Use alert data to track response effectiveness
- **Performance Monitoring**: Analyze alert patterns for system health insights
- **Compliance Reporting**: Generate reports on alert activity and delivery
## What's Next?
Now that you understand the alerts table, you can:
- **[Optimize your alert rules](/guides/alerts)** based on delivery patterns and trigger frequency
- **[Review your notification settings](/guides/user-settings)** to ensure proper contact information and preferences
- **[Analyze log patterns](/guides/logs)** to understand what's triggering your alerts
- **[Use dashboard insights](/guides/dashboard)** to see high-level alert trends and patterns
---
**🚨 Ready to master your alerts?** Start by reviewing recent alert activity to understand your current patterns, then use the status details to optimize delivery and reduce noise. Effective alerting keeps you informed without overwhelming your team!