Skip to content

Add info field to AlertSummary, require consistent KPI sourcing #44

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
sarroutbi merged 1 commit into from
Apr 21, 2026
Merged

Add info field to AlertSummary, require consistent KPI sourcing #44

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions spec/SDD-Keylime-Monitoring-Tool.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -829,7 +829,7 @@ New --> Acknowledged --> UnderInvestigation --> Resolved

**Terminal States:** `Resolved` and `Dismissed` reject all further transitions.

**Summary Computation:** Active alerts (not `Resolved` or `Dismissed`) are counted by severity. Resolved alerts within the last 24 hours are counted separately for the dashboard KPI.
**Summary Computation:** Active alerts (not `Resolved` or `Dismissed`) are counted by severity (`critical`, `warnings`, `info`). Resolved alerts within the last 24 hours are counted separately (`resolved_24h`). All four counters are returned by `GET /api/alerts/summary` and used consistently by both the Dashboard and the Alert Center KPI cards.

**Trace:** Implementation -- `keylime-webtool-backend/src/models/alert_store.rs`

Expand Down Expand Up @@ -878,7 +878,11 @@ The frontend derives attestation KPIs from agent state data when no attestation
| Total Agents | `paginated_response.total_items` or `agents.length` |
| Failed Attestations | Count of agents in `failed`, `invalid_quote`, `tenant_failed` (pull) or `fail`, `timeout` (push) state |
| Success Rate | `((total - failed) / total) * 100` |
| Active Alerts | From `GET /api/alerts/summary` -> `critical` count |
| Active Alerts | From `GET /api/alerts/summary` -> `critical + warnings` count |
| Alert Center: Critical | From `GET /api/alerts/summary` -> `critical` |
| Alert Center: Warnings | From `GET /api/alerts/summary` -> `warnings` |
| Alert Center: Info | From `GET /api/alerts/summary` -> `info` |
| Alert Center: Resolved | From `GET /api/alerts/summary` -> `resolved_24h` |

**Rationale:** Ensures the dashboard displays meaningful data before TimescaleDB attestation history persistence is implemented.

Expand Down
6 changes: 6 additions & 0 deletions spec/SRS-Keylime-Monitoring-Tool.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1507,6 +1507,12 @@ Feature: Alert Lifecycle Workflow
When agent "agent-042" passes a subsequent attestation cycle
Then the System SHOULD automatically resolve the alert
And the resolution reason MUST indicate "auto-resolved on successful re-attestation"

Scenario: Alert Center KPI cards use consistent summary data
Given the alert summary endpoint returns critical=2, warnings=2, info=2, resolved_24h=0
When the user views the Alert Center page
Then all four KPI cards (Critical, Warnings, Info, Resolved) MUST display values from the summary endpoint
And the KPI values MUST NOT change when table filters are applied
```

### FR-048: Alert Auto-Escalation
Expand Down
Loading