Custom Alerts let you create Mini DBA alert rules from your own SQL query on a monitored database server. Use them when the built-in alert catalog does not cover a local business rule, application-specific condition, operational exception, or customer-specific monitoring requirement.
What Custom Alerts Are For
Custom alerts extend the normal Mini DBA alert workflow. They are created from a server's Alerts page and are evaluated by the connected Mini DBA Engine, using the monitored server context and database platform you selected.
Good custom alert candidates include:
- A business table that records failed imports, stuck workflow items, or overdue jobs.
- A platform feature that is important locally but not covered by a built-in Mini DBA alert.
- A customer-specific service-level indicator used by an MSP team.
- A temporary detection rule during an incident, migration, or staged rollout.
Use SQL Server Alerts, Azure SQL Database Alerts, PostgreSQL Alerts, MySQL And MariaDB Alerts, or Oracle Alerts for built-in server alerts. Use custom alerts when you need a monitored condition that only your environment understands.
Create A Custom Alert
- Open the monitored server in the navigation tree.
- Select Alerts.
- Choose New Custom Alert.
- Enter a clear alert name and description.
- Select the query return type.
- Enter the query using the SQL dialect for the selected server type.
- Set the query timeout in seconds.
- Choose Test Query before saving.
- Save the custom alert and confirm it appears in the server alert configuration list.
Custom alerts are stored with the server's alert configuration. Edit an existing custom alert from the alert list, or delete it from the custom alert dialog when it is no longer needed.
Query Return Types
| Type | How It Works | Example Use |
|---|---|---|
| Boolean | Return a single boolean or bit value. The alert fires when the result is true. | Alert when a table contains a failed control row. |
| Numeric | Return a single numeric value. Mini DBA compares it with the alert threshold direction. | Alert when a queue depth is more than the accepted limit. |
| Result Set | Return problem rows. The alert fires when one or more rows are returned. | Alert when any tenant has stale processing state. |
For numeric custom alerts, choose whether the value should alert when it is less than the threshold or more than the threshold. Boolean and result-set alerts are usually better for yes/no business rules, while numeric alerts are better for counts, age, backlog, latency, or size.
Copying Custom Alerts Between Servers
Custom alert definitions are included when you copy, export, or import a server's alert configuration. This lets a DBA or MSP team build a tested custom alert once and apply it to other same-type monitored servers from the Alerts page.
Before copying a custom alert to another server, confirm that the target database has the same schema, object names, permissions, and expected return values. A custom query that works on one customer's database may fail or produce noisy results on another. For full copy and import steps, see Copy, Export, And Import Alert Configuration.
Query Safety And Permissions
Write custom alert queries as read-only checks. The test query path blocks obvious write and schema-change keywords such as DELETE, UPDATE, INSERT, DROP, TRUNCATE, and ALTER, but the safest pattern is still to use a monitoring login with only the permissions required to read the target metadata or application table.
The console sends the test request to the connected Mini DBA Engine. If no engine is selected, or the selected engine is disconnected, the console will show a validation message instead of running the query. If the console and engine versions are out of sync, update the connected engine so the custom alert test method is available.
Testing And Tuning
Use Test Query to confirm that the query returns the shape expected by the selected return type. Keep the timeout low enough to protect monitoring, but high enough for the query to complete under normal load. The console supports a timeout range from 1 to 60 seconds.
Custom alerts should be tuned like built-in alerts:
- Use a name that explains the condition without needing to open the query.
- Put operational context in the description.
- Keep the query selective and indexed.
- Avoid long scans on busy production tables.
- Route only actionable custom alerts to notification channels.
- Review temporary custom alerts after the incident or migration ends.
Remediation For A Custom Alert
When a custom alert fires, start with the query result and description. Identify the business object, database, tenant, job, or queue named by the query. Confirm whether the result is still active, then decide whether the issue belongs to the DBA team, application team, operations team, or customer owner.
If the alert is accurate, fix the underlying business or platform condition. If the alert is noisy, adjust the query, threshold, timeout, routing, or maintenance-window handling. If the alert is no longer needed, delete it so the alert list stays focused.
Related Pages
- Alerts Page
- SQL Server Alerts
- Azure SQL Database Alerts
- PostgreSQL Alerts
- MySQL And MariaDB Alerts
- Oracle Alerts
- Copy, Export, And Import Alert Configuration
- Alert Recipients