Alerting & Notifications
Beacon’s Alerting & Notifications module provides proactive, configurable monitoring of database conditions and performance events. It allows teams to define what matters, set thresholds and conditions, and receive timely notifications when those conditions are met — so issues are addressed before they escalate.
This module answers the question: “When something goes wrong, who needs to know, and how do they find out?”
Capabilities
Section titled “Capabilities”1. Alert Rule Configuration
Section titled “1. Alert Rule Configuration”Beacon allows users to define alert rules based on any monitored signal or condition.
| Configuration Element | Description |
|---|---|
| Alert Name | A human-readable identifier for the rule. |
| Monitored Signal | The metric or condition the alert watches. |
| Threshold | The value or boundary that triggers the alert. |
| Comparison Operator | Above, below, equals, or changes by a defined amount. |
| Evaluation Window | How long the condition must persist before firing. |
| Severity Level | Critical, warning, or informational. |
| Scope | Which database instances the rule applies to. |
| Enabled State | Whether the rule is actively evaluating. |
Operational value: Lets teams encode their operational expectations as automated, continuously evaluated rules.
2. Alert Condition Types
Section titled “2. Alert Condition Types”Beacon supports a range of alert conditions across its monitoring and analysis domains.
| Condition Category | Example Triggers |
|---|---|
| Resource-Based | CPU, memory, or storage exceeding defined limits. |
| Session-Based | Active session counts or idle-in-transaction sessions beyond thresholds. |
| Transaction-Based | Long-running or frequently rolled-back transactions. |
| Lock-Based | Blocking chains exceeding duration or depth limits. |
| Query-Based | Slow queries exceeding time or frequency thresholds. |
| Replication-Based | Replication lag beyond acceptable levels. |
| Availability-Based | Instance unreachable or connection failures. |
| Index-Based | Unused indexes exceeding size thresholds or bloating. |
Operational value: Provides coverage across every dimension of database health, not just infrastructure metrics.
3. Threshold & Anomaly Triggers
Section titled “3. Threshold & Anomaly Triggers”Beacon supports both static thresholds and behavior-based triggering.
| Trigger Type | Description |
|---|---|
| Static Threshold | Fixed value boundary (e.g., CPU above 90%). |
| Relative Threshold | Change relative to a baseline (e.g., 50% increase over normal). |
| Sustained Condition | Condition must persist for a defined duration. |
| Sudden Change | Abrupt deviation from recent behavior. |
| Absence Trigger | Expected signal stops arriving. |
Operational value: Reduces false positives by allowing nuanced conditions rather than simple value comparisons.
4. Alert Severity Levels
Section titled “4. Alert Severity Levels”Beacon classifies alerts by severity to guide response urgency.
| Severity | Meaning | Typical Response |
|---|---|---|
| Critical | Immediate action required; production impact likely. | Immediate investigation. |
| Warning | Degradation detected; may escalate if unaddressed. | Review during working hours. |
| Informational | Notable but non-urgent observation. | Awareness only. |
Operational value: Ensures attention is directed proportionally to actual risk.
5. Notification Channels
Section titled “5. Notification Channels”Beacon delivers alerts through configurable notification channels.
| Channel Category | Description |
|---|---|
| In-Platform Notifications | Alerts appear within the Beacon interface. |
| Email Notifications | Alerts delivered to configured recipients. |
| Webhook Delivery | Alerts forwarded to external systems for integration. |
| Chat Integrations | Alerts delivered to team communication channels. |
Operational value: Alerts reach the people and systems that can act on them, wherever they work.
6. Alert Routing & Assignment
Section titled “6. Alert Routing & Assignment”Beacon allows alerts to be directed to specific recipients based on rules.
| Routing Element | Description |
|---|---|
| Recipient Groups | Named sets of users who receive specific alerts. |
| Instance-Based Routing | Route alerts based on which database triggered them. |
| Severity-Based Routing | Different channels for different severities. |
| Escalation Paths | Define what happens if an alert is not acknowledged. |
| Quiet Hours | Suppress non-critical alerts during defined periods. |
Operational value: Ensures the right people are notified without overwhelming them with irrelevant alerts.
7. Alert Lifecycle Management
Section titled “7. Alert Lifecycle Management”Beacon tracks the full lifecycle of every alert.
| Lifecycle Stage | Description |
|---|---|
| Triggered | Condition met; alert created. |
| Active | Alert is currently firing. |
| Acknowledged | A user has seen and accepted the alert. |
| Resolved | Condition cleared; alert closed. |
| Suppressed | Alert muted by a maintenance window or rule. |
Operational value: Provides a clear audit trail and prevents duplicate or stale alerts from lingering.
8. Alert History & Audit
Section titled “8. Alert History & Audit”Beacon maintains a searchable history of all past alerts.
| Signal | Description |
|---|---|
| Alert Log | Chronological record of all triggered alerts. |
| Resolution Time | How long each alert remained active. |
| Response History | Who acknowledged and when. |
| Recurrence Tracking | Alerts that fire repeatedly. |
| Suppression Record | When alerts were muted and why. |
Operational value: Enables post-incident review and identification of chronic, recurring issues.
9. Maintenance Windows
Section titled “9. Maintenance Windows”Beacon allows planned maintenance to suppress expected alerts.
| Capability | Description |
|---|---|
| Window Definition | Define start and end times for maintenance periods. |
| Scope Selection | Choose which instances or rules are affected. |
| Suppression Behavior | Alerts suppressed during the window are logged, not lost. |
| Post-Window Resume | Alert evaluation resumes automatically after the window. |
Operational value: Prevents alert fatigue during planned downtime.
Alert Views
Section titled “Alert Views”Active Alerts
Section titled “Active Alerts”A live view of all currently firing alerts, prioritized by severity.
Alert Configuration
Section titled “Alert Configuration”Manage rules, thresholds, and routing.
Alert History
Section titled “Alert History”Browse and search past alerts and their outcomes.
Alert Dashboard
Section titled “Alert Dashboard”An aggregated overview of alert volume and trends.
Configuration Options
Section titled “Configuration Options”| Option | Purpose |
|---|---|
| Default Severity | Severity assigned when none is specified. |
| Evaluation Frequency | How often alert conditions are checked. |
| Notification Throttling | Limit duplicate notifications within a window. |
| Auto-Resolution | Automatically resolve alerts when conditions clear. |
| Recipient Defaults | Default recipients for unassigned alerts. |
Operational Scenarios
Section titled “Operational Scenarios”Scenario 1 — Catching a storage trend early A warning alert fires when storage usage crosses 80%. The team expands capacity during a planned window, well before the 100% critical threshold is reached.
Scenario 2 — Escalating a critical lock storm A critical alert fires for a blocking chain exceeding the defined duration. Routing sends the alert to the on-call channel. When it is not acknowledged within 15 minutes, it escalates to the database team lead.
Scenario 3 — Silencing noise during deployment A maintenance window is scheduled during a known deployment. Alerts that would normally fire during connection churn are suppressed and logged, then evaluation resumes automatically.
Summary
Section titled “Summary”Beacon’s Alerting & Notifications module turns monitoring data into proactive action. By supporting flexible conditions, severity-aware routing, lifecycle tracking, and maintenance windows, it ensures teams are informed of what matters — and not overwhelmed by what does not.