🔔 Epic: Alerting System with UI Notification Center

Open crivetimihai opened this issue 3 weeks ago • 0 comments

🔔 Epic: Alerting System with UI Notification Center

Goal

Implement a comprehensive alerting and notification system that enables plugins, services, and system components to generate alerts that are displayed in a centralized notification UI with a bell icon. This provides administrators and users with real-time visibility into security events, policy violations, system health issues, and operational warnings across the entire MCP Gateway ecosystem.

Why Now?

As MCP Gateway grows in production deployments with plugins, federation, A2A agents, and multi-tenant architectures, operational visibility becomes critical:

Plugin Violations Need Visibility: Security plugins (PII filter, deny filter, clearance levels) generate violations that administrators need to see immediately
Proactive Incident Response: Real-time alerts enable faster response to security events, performance degradations, and system anomalies
Audit & Compliance: Regulatory frameworks require notification and escalation of security-relevant events
User Experience: Users need to know when their requests are blocked, throttled, or modified by policies
Federation & A2A Monitoring: Cross-gateway communication and agent behavior need monitoring and alerting
Operational Excellence: DevOps teams need centralized visibility into warnings, errors, and threshold violations

By implementing a unified alerting system, we enable all components to emit structured alerts while providing administrators with a modern, real-time notification center.

📖 User Stories

US-1: Platform Admin - View Real-Time Alerts in UI

As a Platform Administrator I want to see a bell icon in the Admin UI with a badge showing unread alert count So that I can quickly access critical notifications without checking logs

Acceptance Criteria:

Given I am logged into the Admin UI
When there are 5 unread alerts in the system
Then I should see:
  - Bell icon (🔔) in the top navigation bar
  - Red badge with number "5" overlaid on the bell
  - Badge pulses or animates for high-severity alerts
When I click the bell icon
Then a dropdown panel should open showing:
  - List of recent alerts (most recent first)
  - Alert severity (critical, warning, info) with color coding
  - Alert source (plugin name, service, component)
  - Timestamp (relative: "2 minutes ago")
  - Brief message preview (first 80 characters)
  - "Mark all as read" button
  - "View all alerts" link to full alert history page
When I click an individual alert
Then the alert should:
  - Expand to show full details
  - Mark as read (remove from unread count)
  - Provide action buttons if applicable (e.g., "Review", "Dismiss", "Investigate")

Technical Requirements:

HTMX-powered dropdown with Alpine.js interactivity
WebSocket or SSE for real-time alert delivery
Badge counter updates without page refresh
Responsive design for mobile/tablet
Accessibility: keyboard navigation, ARIA labels

US-2: Plugin Developer - Emit Alerts from Plugins

As a Plugin Developer I want to emit alerts from my plugin when violations or events occur So that administrators are notified of security policy enforcement

Acceptance Criteria:

Given I am developing a security plugin (e.g., PIIFilterPlugin)
When the plugin detects a PII leak attempt
Then I should be able to emit an alert:

from mcpgateway.services.alert_service import AlertService

alert = AlertService.create_alert(
    severity="warning",
    category="security",
    source="PIIFilterPlugin",
    title="PII Redaction Applied",
    message="Detected and redacted SSN pattern in tool response",
    metadata={
        "tool_name": "customer-db-query",
        "user_id": "[email protected]",
        "pattern_matched": "ssn",
        "request_id": "req-12345"
    },
    actions=[
        {"label": "Review Tool", "url": "/admin/tools/customer-db-query"},
        {"label": "View Audit Log", "url": "/admin/audit?request_id=req-12345"}
    ]
)

And the alert should be:
  - Stored in the database (alerts table)
  - Broadcast to connected UI clients via WebSocket/SSE
  - Appear in the notification bell dropdown
  - Logged for audit purposes

Technical Requirements:

Simple API: AlertService.create_alert()
Support severity levels: critical, warning, info
Support categories: security, performance, system, plugin, federation, a2a
Metadata as JSON for flexible structured data
Optional action buttons with URLs
Automatic alert ID and timestamp generation

US-3: Security Engineer - Configure Alert Rules and Thresholds

As a Security Engineer I want to configure alert rules and thresholds So that I control when and how alerts are generated

Acceptance Criteria:

Given I navigate to /admin/alerts/rules
When I create a new alert rule:
  - Name: "High Rate of PII Redactions"
  - Condition: "PII redactions > 10 per minute"
  - Severity: "critical"
  - Notification channels: ["ui", "email", "webhook"]
Then the system should:
  - Store the rule in the database
  - Evaluate the condition against incoming events
  - Generate alerts when threshold exceeded
  - Send notifications to configured channels
  - Include throttling to prevent alert storms (max 1 per 5 minutes)

When I edit an existing rule
Then I should be able to:
  - Change condition expression
  - Update severity level
  - Enable/disable rule
  - Add/remove notification channels
  - Test rule with historical data

Technical Requirements:

Rule engine for condition evaluation
Support metric aggregation (count, rate, average)
Time windows (per minute, per hour, per day)
Rule priority and ordering
Alert throttling and deduplication
UI for rule management (HTMX)

US-4: Operations Engineer - Receive Multi-Channel Notifications

As an Operations Engineer I want to receive alerts via multiple channels (UI, email, Slack, webhook) So that I am notified even when not actively using the UI

Acceptance Criteria:

Given I have configured notification preferences:
  notification_channels:
    ui: true
    email: true
    webhook: "https://hooks.slack.com/services/XXX"
    
When a critical alert is generated
Then I should receive notifications via:
  - UI: Bell icon badge increment, dropdown update
  - Email: Structured email with alert details and action links
  - Webhook: POST request to Slack with formatted message

When a warning alert is generated
Then I should receive:
  - UI: Notification in dropdown
  - Email: Only if configured for warning-level alerts

When an info alert is generated
Then I should receive:
  - UI: Notification in dropdown only

Technical Requirements:

Alert routing based on severity and channel preferences
Email templates with HTML formatting
Webhook payload formatting (Slack, Teams, generic)
Retry logic for failed deliveries
Rate limiting per channel to prevent spam
Configuration via environment variables and Admin UI

US-5: Platform Admin - View Alert History and Audit Trail

As a Platform Administrator I want to view comprehensive alert history with filtering and search So that I can analyze patterns and investigate incidents

Acceptance Criteria:

Given I navigate to /admin/alerts/history
Then I should see:
  - Paginated list of all alerts (50 per page)
  - Filters: severity, category, source, date range, read/unread
  - Search: full-text search on title and message
  - Sort: by timestamp (desc/asc), severity, source
  - Export: Download as CSV/JSON for SIEM integration

When I filter by:
  - Severity: "critical"
  - Category: "security"
  - Date range: "Last 7 days"
Then the list should update to show only matching alerts

When I click on an alert
Then I should see:
  - Full alert details (all metadata)
  - Related events (linked by request_id or correlation_id)
  - Timeline of related alerts
  - Action history (who marked as read, when)

Technical Requirements:

Database queries with efficient indexing
Full-text search support (SQLite FTS or PostgreSQL)
CSV/JSON export functionality
Pagination with offset/limit
Related alert correlation
Retention policy (configurable, default 90 days)

US-6: Plugin Admin - Configure Per-Plugin Alert Settings

As a Plugin Administrator I want to enable/disable alerts for each plugin and configure severity thresholds So that I control alert noise and focus on relevant events

Acceptance Criteria:

Given I navigate to /admin/plugins/pii_filter/settings
When I configure alert settings:
  alerts:
    enabled: true
    min_severity: "warning"  # Ignore info-level alerts
    throttle_interval: 300   # Max 1 alert per 5 minutes
    notification_channels: ["ui", "email"]
    
Then the plugin should:
  - Only emit alerts at warning or critical severity
  - Throttle repeated alerts within 5-minute windows
  - Route alerts to UI and email channels only
  - Respect global alert service configuration

When I disable alerts for a plugin
Then:
  - No alerts should be generated by that plugin
  - Existing alerts should remain in history
  - Bell icon should not increment for that plugin's events

Technical Requirements:

Per-plugin alert configuration schema
Integration with plugin config.yaml
UI for managing alert settings per plugin
Throttling/deduplication logic
Alert suppression during maintenance windows

US-7: Developer - Real-Time Alert Streaming via WebSocket/SSE

As a UI Developer I want to receive real-time alert updates via WebSocket or SSE So that the UI updates immediately when new alerts arrive

Acceptance Criteria:

Given I have an authenticated WebSocket connection to /ws/alerts
When a new alert is created with severity "critical"
Then I should receive a WebSocket message:
{
  "type": "alert_created",
  "alert": {
    "id": "alert-uuid",
    "severity": "critical",
    "category": "security",
    "source": "PIIFilterPlugin",
    "title": "PII Redaction Applied",
    "message": "Detected and redacted SSN...",
    "timestamp": "2025-01-19T12:34:56Z",
    "read": false,
    "metadata": {...}
  }
}

And the UI should:
  - Increment the bell badge counter
  - Add the alert to the dropdown list
  - Show a toast notification for critical alerts
  - Play a sound (optional, user preference)
  - Animate the bell icon

When I mark an alert as read
Then a WebSocket message should broadcast:
{
  "type": "alert_read",
  "alert_id": "alert-uuid"
}

And all connected clients for that user should update the UI

Technical Requirements:

WebSocket endpoint: /ws/alerts (per-user authentication)
SSE endpoint: /stream/alerts (fallback for WebSocket)
Message types: alert_created, alert_read, alert_deleted
Per-user filtering (users only see their relevant alerts)
Connection management and reconnection logic
Heartbeat/ping-pong to keep connections alive

🏗 Architecture

Alert Flow

sequenceDiagram
    participant Plugin as Plugin/Service
    participant AlertSvc as AlertService
    participant DB as Database
    participant WSMgr as WebSocketManager
    participant UI as Admin UI Client
    participant Email as Email Service
    participant Webhook as Webhook Service

    Plugin->>AlertSvc: create_alert(severity, title, message)
    AlertSvc->>DB: INSERT INTO alerts
    DB-->>AlertSvc: alert_id
    
    par Broadcast to UI
        AlertSvc->>WSMgr: broadcast_alert(alert)
        WSMgr->>UI: WebSocket: {"type": "alert_created", "alert": {...}}
        UI->>UI: Update bell badge, show in dropdown
    and Send Email
        AlertSvc->>Email: send_notification(alert)
        Email->>Email: Render HTML template
        Email-->>AlertSvc: sent
    and Send Webhook
        AlertSvc->>Webhook: post_webhook(alert)
        Webhook->>Webhook: POST to Slack/Teams
        Webhook-->>AlertSvc: delivered
    end
    
    AlertSvc-->>Plugin: alert_id
    
    Note over UI: User clicks alert
    UI->>AlertSvc: PATCH /alerts/{id}/read
    AlertSvc->>DB: UPDATE alerts SET read=true
    AlertSvc->>WSMgr: broadcast_alert_read(alert_id)
    WSMgr->>UI: WebSocket: {"type": "alert_read", "alert_id": "..."}
    UI->>UI: Decrement badge, update UI

Database Schema

-- Alerts table
CREATE TABLE alerts (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    severity VARCHAR(20) NOT NULL CHECK (severity IN ('critical', 'warning', 'info')),
    category VARCHAR(50) NOT NULL,  -- security, performance, system, plugin, federation, a2a
    source VARCHAR(100) NOT NULL,   -- Plugin name, service name, component
    title VARCHAR(200) NOT NULL,
    message TEXT NOT NULL,
    metadata JSONB,                 -- Flexible structured data
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    read BOOLEAN DEFAULT FALSE,
    read_at TIMESTAMP,
    read_by VARCHAR(255),
    user_id UUID REFERENCES users(id),  -- NULL for global alerts
    tenant_id UUID,
    correlation_id VARCHAR(100),    -- For grouping related alerts
    actions JSONB,                  -- Action buttons: [{"label": "Review", "url": "/..."}]
    
    INDEX idx_severity (severity),
    INDEX idx_category (category),
    INDEX idx_created_at (created_at),
    INDEX idx_read (read),
    INDEX idx_user_id (user_id),
    INDEX idx_correlation_id (correlation_id)
);

-- Alert rules (for threshold-based alerting)
CREATE TABLE alert_rules (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name VARCHAR(100) UNIQUE NOT NULL,
    description TEXT,
    condition_expression TEXT NOT NULL,  -- e.g., "pii_redactions > 10 per minute"
    severity VARCHAR(20) NOT NULL,
    category VARCHAR(50) NOT NULL,
    enabled BOOLEAN DEFAULT TRUE,
    throttle_seconds INTEGER DEFAULT 300,  -- Min time between alerts
    notification_channels JSONB,     -- ["ui", "email", "webhook"]
    created_by UUID REFERENCES users(id),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    last_triggered_at TIMESTAMP
);

-- Notification preferences (per-user)
CREATE TABLE notification_preferences (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID REFERENCES users(id) ON DELETE CASCADE,
    channel VARCHAR(50) NOT NULL,    -- ui, email, webhook
    enabled BOOLEAN DEFAULT TRUE,
    min_severity VARCHAR(20),        -- Only notify for this severity or higher
    config JSONB,                    -- Channel-specific config (email address, webhook URL)
    UNIQUE(user_id, channel)
);

-- Alert acknowledgments (for tracking who handled what)
CREATE TABLE alert_acknowledgments (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    alert_id UUID REFERENCES alerts(id) ON DELETE CASCADE,
    user_id UUID REFERENCES users(id),
    acknowledged_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    action_taken TEXT,
    notes TEXT
);

📋 Implementation Tasks

Phase 1: Core Alert Service ✅

[ ] Alert Service Implementation
- [ ] Create mcpgateway/services/alert_service.py
- [ ] Implement AlertService class with methods:
  - [ ] create_alert(severity, category, source, title, message, metadata, actions)
  - [ ] get_alert(alert_id)
  - [ ] get_alerts(filters, pagination)
  - [ ] mark_as_read(alert_id, user_id)
  - [ ] mark_all_as_read(user_id)
  - [ ] delete_alert(alert_id)
  - [ ] get_unread_count(user_id)
- [ ] Alert severity enum: critical, warning, info
- [ ] Alert category enum: security, performance, system, plugin, federation, a2a
[ ] Database Schema
- [ ] Create Alembic migration for alerts table
- [ ] Create migration for alert_rules table
- [ ] Create migration for notification_preferences table
- [ ] Create migration for alert_acknowledgments table
- [ ] Add indexes for performance
[ ] ORM Models
- [ ] Create models.Alert with relationships
- [ ] Create models.AlertRule
- [ ] Create models.NotificationPreference
- [ ] Create models.AlertAcknowledgment

Phase 2: Real-Time Broadcasting ✅

[ ] WebSocket Manager
- [ ] Create mcpgateway/websocket_manager.py
- [ ] Implement connection management (per-user connections)
- [ ] Implement broadcast_alert(alert, user_id) method
- [ ] Implement broadcast_alert_read(alert_id, user_id) method
- [ ] Handle connection lifecycle (connect, disconnect, reconnect)
- [ ] Add heartbeat/ping-pong for connection health
[ ] WebSocket Endpoint
- [ ] Add /ws/alerts WebSocket route in main.py
- [ ] Authenticate connections (JWT or session)
- [ ] Filter alerts by user permissions
- [ ] Handle incoming messages (mark_as_read, dismiss)
[ ] SSE Fallback
- [ ] Add /stream/alerts SSE endpoint
- [ ] Stream alerts in real-time
- [ ] Support reconnection with Last-Event-ID

Phase 3: Admin UI - Bell Icon & Dropdown ✅

[ ] Navigation Bar Update
- [ ] Add bell icon (🔔) to templates/layout.html navigation
- [ ] Add badge counter (HTMX: hx-get="/admin/alerts/unread-count" with polling)
- [ ] Implement Alpine.js dropdown for alerts
[ ] Alert Dropdown Component
- [ ] Create templates/alerts/dropdown.html (HTMX partial)
- [ ] Display recent 10 alerts
- [ ] Show severity color coding (red, orange, blue)
- [ ] Show relative timestamps ("2 minutes ago")
- [ ] "Mark all as read" button
- [ ] "View all alerts" link
[ ] Endpoints for Dropdown
- [ ] GET /admin/alerts/unread-count (returns JSON: {"count": 5})
- [ ] GET /admin/alerts/recent (returns HTMX partial with alert list)
- [ ] PATCH /admin/alerts/{id}/read (mark single alert as read)
- [ ] POST /admin/alerts/mark-all-read (mark all as read for user)
[ ] Real-Time Updates
- [ ] WebSocket integration in layout.html JavaScript
- [ ] Listen for alert_created events and update badge/dropdown
- [ ] Listen for alert_read events and update UI
- [ ] Toast notifications for critical alerts

Phase 4: Admin UI - Alert History Page ✅

[ ] Alert History Page
- [ ] Create templates/alerts/history.html
- [ ] Paginated alert list (50 per page)
- [ ] Filters: severity, category, source, date range, read/unread
- [ ] Search: full-text search on title and message
- [ ] Sort: timestamp, severity, source
- [ ] Export: CSV/JSON download buttons
[ ] Endpoints for History
- [ ] GET /admin/alerts/history (render page)
- [ ] GET /admin/alerts/history/data (HTMX partial for table rows)
- [ ] GET /admin/alerts/{id} (alert detail modal)
- [ ] GET /admin/alerts/export (CSV/JSON export)
[ ] Alert Detail Modal
- [ ] Show full metadata as formatted JSON
- [ ] Show action buttons
- [ ] Show acknowledgment history
- [ ] Show related alerts (by correlation_id)

Phase 5: Alert Rules Engine ✅

[ ] Rule Engine
- [ ] Create mcpgateway/services/alert_rule_service.py
- [ ] Implement RuleEngine class
- [ ] Parse condition expressions (e.g., "pii_redactions > 10 per minute")
- [ ] Evaluate conditions against metrics/events
- [ ] Generate alerts when conditions met
- [ ] Implement throttling (max 1 alert per N seconds)
[ ] Metrics Collection
- [ ] Integrate with existing metrics (Prometheus counters)
- [ ] Track plugin events (pii_redactions, denials, etc.)
- [ ] Support aggregation functions (count, rate, sum, avg)
- [ ] Time windows (per minute, per hour, per day)
[ ] Rule Management UI
- [ ] Create templates/alerts/rules.html
- [ ] List existing rules
- [ ] Create/edit/delete rules
- [ ] Enable/disable rules
- [ ] Test rule against historical data
[ ] Endpoints for Rules
- [ ] GET /admin/alerts/rules (list rules)
- [ ] POST /admin/alerts/rules (create rule)
- [ ] PATCH /admin/alerts/rules/{id} (update rule)
- [ ] DELETE /admin/alerts/rules/{id} (delete rule)
- [ ] POST /admin/alerts/rules/{id}/test (test rule)

Phase 6: Multi-Channel Notifications ✅

[ ] Email Notifications
- [ ] Create mcpgateway/services/email_service.py
- [ ] SMTP configuration via environment variables
- [ ] HTML email templates for alerts
- [ ] Send email with alert details and action links
- [ ] Retry logic for failed sends
[ ] Webhook Notifications
- [ ] Create mcpgateway/services/webhook_service.py
- [ ] Support generic webhook POST requests
- [ ] Format payloads for Slack (incoming webhooks)
- [ ] Format payloads for Microsoft Teams
- [ ] Retry logic with exponential backoff
[ ] Notification Preferences UI
- [ ] Create templates/alerts/preferences.html
- [ ] Enable/disable channels (UI, email, webhook)
- [ ] Set min severity per channel
- [ ] Configure email address
- [ ] Configure webhook URLs
[ ] Endpoints for Preferences
- [ ] GET /admin/alerts/preferences (get user preferences)
- [ ] PUT /admin/alerts/preferences (update preferences)

Phase 7: Plugin Integration ✅

[ ] AlertService Integration in Plugins
- [ ] Update PIIFilterPlugin to emit alerts on redaction
- [ ] Update DenyFilterPlugin to emit alerts on denials
- [ ] Update SecurityClearancePlugin to emit alerts on violations
- [ ] Update RegexFilterPlugin to emit alerts on matches
[ ] Per-Plugin Alert Settings
- [ ] Add alerts section to plugin config schema
- [ ] Fields: enabled, min_severity, throttle_interval, notification_channels
- [ ] Respect plugin-level alert configuration
- [ ] UI for managing plugin alert settings
[ ] Plugin Configuration UI
- [ ] Update templates/plugins/{plugin}/settings.html
- [ ] Add alert configuration section
- [ ] Enable/disable alerts for plugin
- [ ] Set severity threshold
- [ ] Set throttle interval

Phase 8: Testing ✅

[ ] Unit Tests
- [ ] Test AlertService CRUD operations
- [ ] Test unread count calculation
- [ ] Test alert filtering and pagination
- [ ] Test RuleEngine condition evaluation
- [ ] Test throttling and deduplication
- [ ] Test email/webhook formatting
[ ] Integration Tests
- [ ] Test WebSocket connections and broadcasts
- [ ] Test SSE streaming
- [ ] Test plugin alert emission
- [ ] Test multi-channel notification delivery
- [ ] Test alert rules triggering
[ ] UI Tests
- [ ] Playwright tests for bell icon interaction
- [ ] Test dropdown opening/closing
- [ ] Test marking alerts as read
- [ ] Test alert history page filtering
- [ ] Test real-time updates via WebSocket

Phase 9: Documentation ✅

[ ] User Guide
- [ ] Create docs/docs/manage/alerts.md
- [ ] Document alert system overview
- [ ] Document UI navigation
- [ ] Document alert rules configuration
- [ ] Document notification preferences
[ ] Developer Guide
- [ ] Document AlertService API
- [ ] Document how to emit alerts from plugins
- [ ] Document WebSocket protocol
- [ ] Document alert rule condition syntax
[ ] API Documentation
- [ ] OpenAPI spec for alert endpoints
- [ ] Example API calls with curl

Phase 10: Quality & Polish ✅

[ ] Code Quality
- [ ] Run make autoflake isort black
- [ ] Run make flake8 and fix issues
- [ ] Run make pylint and address warnings
- [ ] Pass make verify
[ ] Performance
- [ ] Add database indexes for alert queries
- [ ] Optimize WebSocket broadcasts for many connections
- [ ] Implement alert archival/cleanup (>90 days)

⚙️ Configuration Example

Environment Variables

# Alerting configuration
MCPGATEWAY_ALERTS_ENABLED=true
MCPGATEWAY_ALERTS_RETENTION_DAYS=90
MCPGATEWAY_ALERTS_WEBSOCKET_ENABLED=true
MCPGATEWAY_ALERTS_EMAIL_ENABLED=true
MCPGATEWAY_ALERTS_WEBHOOK_ENABLED=true

# Email configuration
SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
[email protected]
SMTP_PASSWORD=your-password
SMTP_FROM=MCP Gateway <[email protected]>

# Webhook configuration
ALERT_WEBHOOK_SLACK=https://hooks.slack.com/services/XXX/YYY/ZZZ
ALERT_WEBHOOK_TEAMS=https://outlook.office.com/webhook/XXX

Plugin Alert Configuration

plugins:
  - name: "PIIFilterPlugin"
    kind: "plugins.pii_filter.pii_filter.PIIFilterPlugin"
    mode: "enforce"
    config:
      patterns:
        ssn: '\b\d{3}-\d{2}-\d{4}\b'
      
      # Alert configuration
      alerts:
        enabled: true
        min_severity: "warning"
        throttle_interval: 300  # Max 1 alert per 5 minutes
        notification_channels: ["ui", "email"]
        metadata:
          support_url: "https://wiki.example.com/pii-policy"

✅ Success Criteria

[ ] Bell icon appears in Admin UI navigation with unread badge
[ ] Alerts display in real-time dropdown
[ ] WebSocket/SSE delivers alerts to UI without page refresh
[ ] Alerts stored in database with efficient queries
[ ] Alert history page with filtering and search works
[ ] Alert rules engine triggers threshold-based alerts
[ ] Multi-channel notifications (email, webhook) deliver successfully
[ ] Plugins emit alerts for violations
[ ] Per-plugin alert settings configurable via UI
[ ] 80%+ test coverage for alert service and UI
[ ] Documentation complete
[ ] Code passes make verify

🏁 Definition of Done

[ ] AlertService implemented with full CRUD
[ ] Database schema migrated
[ ] WebSocket/SSE endpoints functional
[ ] Bell icon UI component complete
[ ] Alert dropdown with real-time updates
[ ] Alert history page with filters/search
[ ] Alert rules engine working
[ ] Email and webhook notifications sending
[ ] Plugin integration complete (PII, deny, clearance)
[ ] Per-plugin alert configuration UI
[ ] 80%+ unit test coverage
[ ] Integration tests passing
[ ] Playwright UI tests passing
[ ] Documentation complete
[ ] Code quality checks passing

📝 Additional Notes

🔹 Real-Time Architecture: Uses WebSocket for push notifications with SSE fallback

🔹 Alert Retention: Default 90-day retention with configurable cleanup

🔹 Performance: Indexed queries, connection pooling, throttling to prevent alert storms

🔹 Security: Per-user alert filtering, authenticated WebSocket connections

🔹 Extensibility: Plugins can emit custom alerts with structured metadata

🔹 Compliance: Audit trail of all alerts for regulatory requirements

🔗 Related Issues

See issue #1245 for epic template reference

📚 References

Nov 19 '25 08:11 crivetimihai