Overview
Bifrost records every alert evaluation outcome in alert history. Each record captures the rule that was evaluated, the scope and target, the metric values at evaluation time, the delivery channel (if applicable), and the outcome status. Alert history is stored in the configured logs store. PostgreSQL and ClickHouse logs stores both support history writes, filtering, and recovery of alert state. With ClickHouse, Bifrost creates anenterprise_alert_history table with the configured history_retention_days TTL.
Bifrost uses its shared key-value store for live rule cooldown, channel cooldown, and reset-cycle checks. After startup or a leadership change, the alerting engine bulk-loads only the latest relevant sent timestamps and reset-cycle identities from history before it can dispatch alerts. Normal evaluation sweeps do not query alert history for each rule or channel.
With ClickHouse, a cold recovery performs an immediate read and a delayed second read before dispatch starts. This allows replicated ClickHouse tables time to converge and reduces duplicate notifications after failover.
Alert history records
Open Alerting in the Bifrost dashboard and select the History tab to review past alert activity. Each history record contains:| Field | Description |
|---|---|
| Time | When the evaluation was recorded. |
| Rule | The rule that was evaluated. |
| Channel | The channel that was notified, or empty for cooldown skips. |
| Scope | The scope type and ID the rule applied to. |
| Target | The budget target (target_type and target_id), if the rule targets one. |
| Status | Delivery outcome: sent, failed, or skipped. |
Statuses
Each history record has one of three statuses:| Status | Meaning |
|---|---|
sent | The alert was successfully delivered to the channel. |
failed | Delivery was attempted but failed (for example, network error or unsupported channel type). |
skipped | The rule matched but delivery was suppressed by a cooldown. |
status_detail field indicates the reason:
"skipped due to rule cooldown"- the rule-level cooldown was active."skipped due to channel cooldown"- the channel-level cooldown was active.
status_detail field contains the error (for example, "delivery failed" or "unsupported alert channel type: ...").
Evaluation input
Each history record stores the metric values that were evaluated. For a matched rule, this includes the specific values that caused the expression to evaluate totrue. Example for a budget alert:
API
The alert history API is available at/api/alerting/history.
| Method | Endpoint | Description |
|---|---|---|
GET | /history | Paginated history with filters. |
| Parameter | Type | Description |
|---|---|---|
limit | integer | Maximum records to return. Default 25. |
offset | integer | Records to skip for pagination. Default 0. |
status | string (comma-separated) | Filter by status: sent, failed, skipped. |
scope_type | string (comma-separated) | Filter by scope: virtual_key, team, customer. |
channel_type | string (comma-separated) | Filter by channel: slack, microsoft_teams, pagerduty, webhook. |
id is numeric with PostgreSQL and a UUID string with ClickHouse.
Next steps
Alert Rules
Tune conditions, scopes, and cooldowns based on what you see in history.
Alert Channels
Reconfigure channels if you see delivery failures.

