Alerts page


Licence requirement: Alert evaluation, configuration, history, MCP alert exposure and notifications require a trial or licensed Engine. Community Edition keeps monitoring and diagnostics for one server but does not evaluate, persist, expose or send alerts.

The Alerts page helps teams review and triage conditions detected by Mini DBA across monitored database servers. It is the main console page for understanding what currently needs attention.

Mini DBA alerts page

What alerts are for

Alerts help identify problems such as availability issues, health check failures, performance thresholds, failed monitoring checks, capacity concerns, and platform-specific conditions.

Use alerts to move from "something is wrong" to the affected engine, server, database, metric, or query area.

Community Edition alert availability

Alerting requires a trial or licensed Mini DBA Engine. Community Edition continues to provide live monitoring and diagnostic pages, but a Community engine does not evaluate alerts, store alert history, expose alert records, or send notifications through email, Slack, Microsoft Teams, PagerDuty, Jira, or other channels.

When an Engine trial expires, it automatically transitions to Community Edition and these alert restrictions take effect during license revalidation; no restart or manual edition change is required.

Distributed Engine builds apply alert entitlement from the Engine's validated licence state. Internal development builds may use a local-only debug entitlement for testing; that bypass is not included in Release builds.

The Console keeps each server's Alerts node visible so the edition difference is discoverable. When a server is monitored by a Community Edition engine, selecting that node opens an explanation instead of an empty Alerts page. A direct link to the server's Alerts page shows the same guidance and does not load alert configuration or history.

This rule is evaluated per engine. In a Console connected to both licensed and Community engines, servers owned by licensed engines retain full alert functionality. See Licensing for Community Edition and multi-engine rules.

Alert workflow

  1. Open Alerts.
  2. Filter or sort by severity, server, database platform, status, or time.
  3. Review the alert message and affected object.
  4. Open the related server page from the navigation tree.
  5. Use activity, waits, queries, memory, files, logs, or health check pages to investigate.
  6. Confirm notification routing in alert recipients, recipient groups, and integration settings.

Alert scope in multi-Engine mode

In Multi-Engine Mode, alert scope depends on where you are in the Console.

Use the global Alerts page Current tab when you want active alerts from all connected engines and all monitored servers. This is the estate-wide live triage view and is the best place to answer "what is alerting right now?"

Use the current selected engine context when you want to focus on one customer, site, or engine estate. Select the engine, then use the navigation tree and server-specific Alerts pages. In Multi-Engine Mode, the navigation tree is filtered to the selected engine. Server-specific Alerts pages show current, uncleared, history, configure, and maintenance-window information for that server.

The global Alerts page Uncleared and History tabs are loaded through the current selected engine service. To review another engine's uncleared or historical alerts, switch to that engine and refresh the tab.

Need Where To Go
Current active alerts across all engines Global Alerts, Current tab
Current active alerts for one selected engine Select the engine, then use its server tree and server-specific Alerts pages
Uncleared or historical alerts for the selected engine Global Alerts, Uncleared or History tab
Alerts for one monitored server The server's Alerts page
Alert thresholds, copy/import/export, and maintenance windows The server's Alerts page, Configure, Copy Config, and Maintenance Windows tabs

Copy, export, and import alert configuration

Use Copy, Export, And Import Alert Configuration when you need to reuse alert policies across same-type servers or move alert configuration between Mini DBA Engine instances. The server Alerts page Configure tab includes Copy Config, which can copy from another monitored server into the current server, copy the current server to selected target servers, copy between connected engines in Multi-Engine Mode, or import from an exported trigger file.

Copying alert configuration overwrites the target server's current alert thresholds and notification settings. Review recipients, recipient groups, custom alert SQL, maintenance windows, and customer-specific routing before applying a copied policy broadly.

Database-specific alert scope

Some alert rules evaluate database-scoped data. Their configuration modal includes a Databases tab where each discovered database or Oracle PDB can be included or excluded. All databases are included by default. Uncheck a database when that particular alert is not relevant to it; the database remains monitored elsewhere in Mini DBA.

The database filter is offered only when the Engine has data that can be scoped honestly. For example, Oracle RMAN Backup Age can exclude PDBs from its protected scope, and Stale Table Statistics can ignore the current PDB. Instance-wide conditions and RMAN job-failure rows do not show this filter when their sampled data cannot identify an individual database reliably.

If every protected Oracle database/PDB is excluded from RMAN Backup Age, the Engine suppresses that alert and records the exclusion in its evaluation details. Excluding only some PDBs leaves the instance/CDB-wide backup-age measurement active for the remaining protected scope; it does not manufacture a separate RMAN age per PDB.

Amazon RDS and Aurora cloudwatch alerts

For Amazon RDS and Aurora PostgreSQL, MySQL, and SQL Server targets, Mini DBA evaluates cloud-native rules from the Engine's existing AWS credential source. These include CPU utilisation, freeable memory, provisioned RDS free storage, read/write latency, burstable-instance CPU-credit balance, and replica lag. RDS SQL Server also has CloudWatch TempDB data-file and log-file usage rules.

CloudWatch values are not treated as operating-system data. Mini DBA hides cloud-inappropriate on-premises rules and labels the AWS metric source in the alert details. Storage-latency and CPU-credit rules are disabled by default because their acceptable values depend on workload and instance class. Aurora does not expose the provisioned-RDS free-storage rule because Aurora storage grows automatically.

Mini DBA can also import matching AWS/RDS CloudWatch metric alarms as read-only Mini DBA alerts. An AWS ALARM appears as Major and INSUFFICIENT_DATA as Minor; OK clears the imported alert. Imported alarms include an AWS CloudWatch link in their details. Mini DBA never creates, edits, deletes, acknowledges, or changes AWS alarms. When an imported AWS alarm is actively in ALARM for the same metric, it is authoritative and suppresses the duplicate Mini DBA cloud-metric alert.

The AWS identity needs the existing CloudWatch metric permissions plus cloudwatch:DescribeAlarms for imported alarms. If that permission is absent, the server Alerts page explains the missing permission; database monitoring and Mini DBA-native AWS metric alerts continue. Set CloudProviders:AWS:ImportCloudWatchAlarms=false on an Engine only when alarm discovery must be disabled while metrics remain enabled.

Custom alerts

Use Custom Alerts when a monitored server needs a user-defined query alert that is not covered by the built-in Mini DBA alert catalog. Custom alerts are created from a server's Alerts page and can use Boolean, Numeric, or Result Set query return types.

Custom alerts are useful for local business rules, application queues, customer-specific service indicators, or temporary incident checks. They still follow the normal Mini DBA alert workflow, so review routing, thresholds, descriptions, and ownership before sending them to notification channels.

Use Alert Triage With AI when you want Mini DBA AI Assistant to summarize active alerts, group related symptoms, and create an investigation plan from alert, metric, and session context.

Notification setup

For alerts to reach people outside the console, configure:

Troubleshooting missing alerts

  • If the server is monitored by a Community Edition engine, connect it through a trial or licensed engine to enable alerts.
  • Confirm the server is licensed and actively monitored.
  • Confirm the engine is connected in Settings.
  • Check Service Log for sampling or alert-processing errors.
  • Confirm recipients and integrations are enabled.
  • Confirm the relevant alert rule or health check is active.

Alert triage tips

Triage alerts by severity, business impact, and recency. A new warning on a critical production server can matter more than an older high-severity alert on a test system. When multiple alerts fire together, look for the earliest meaningful signal and the shared engine, server, database, or workload.

Alerts should lead to a next action: investigate, escalate, suppress by policy, tune the threshold, or document acceptance. Repeating alerts are especially important because they either show an unresolved problem or a threshold that no longer matches the environment.

Alerts FAQ

Are alerts the same as root cause?

No. Alerts identify conditions. Use the related monitoring pages to diagnose cause and impact.

Why are alerts missing from notifications?

Check alert routing, recipient availability, integration settings, service logs, and whether the alert severity is configured for that channel.

Should I clear alerts manually?

Follow your team's process. Confirm the condition has recovered and document any action taken.

How do I see alerts from every connected Engine?

Open the global Alerts page and use the Current tab for active alerts across all connected engines. Use Enterprise View for a dashboard-style cross-engine health view.

How do I focus on one selected Engine?

Select the engine you want to investigate, then use the filtered navigation tree and server-specific Alerts pages. For uncleared and historical alerts, switch to the engine and refresh the global Alerts tab.

Related pages