In Flashduty On-call
You can obtain an integration push URL in either of the following ways.
Use a dedicated integration
- In the Flashduty console, select Channel and open a channel
- Select Configuration → Integrations → Private integration, then click Add an integration
- Select Redgate SQL Monitor, then click Save
- Open the generated integration card and copy the Push URL
Use a shared integration
- In the Flashduty console, select Integration Center → Alert Events
- Select Redgate SQL Monitor and enter an integration name
- Configure the default route and select a channel; after creation, add more rules under Route if needed
- Click Save and copy the generated Push URL
Configure Redgate Monitor
Webhook notifications are configured in the Redgate Monitor web console, apply to every alert raised by that Base Monitor, and require administrator permissions. The machine that runs the Base Monitor service must be able to reach the Flashduty push URL.
1
Open the notification settings
- Sign in to the Redgate Monitor web console and open the Configuration page
- Under Alerts, select Notification settings and find the Webhook notifications section
2
Configure the webhook
- Choose when Redgate Monitor sends webhook messages
- Select the Default message format. Flashduty parses the JSON fields of the default message and does not support a custom message
- Paste the full Flashduty push URL into URL. The URL must include
integration_key - No additional HTTP headers are needed. Flashduty authenticates the request by the
integration_keyin the URL - Save the settings
3
Verify
- Click Send Test Notification to confirm that Redgate Monitor can send messages to Flashduty. Redgate does not document the content of the test message; if it creates an alert in Flashduty, close that alert manually
- Wait for a real alert to be raised and confirm that Flashduty receives an active alert. After the alert ends in Redgate Monitor, confirm that the Flashduty alert recovers
If the Base Monitor reaches the internet through a proxy, configure the proxy on the Base Monitor machine as described in the Proxy configuration section of Setting up Webhook notifications.
Alert Key
A Redgate Monitor alert ID (
id) is unique only within a single Base Monitor, so Flashduty computes the Alert Key from both the Base Monitor identifier (baseMonitorGuid) and the alert ID (id). The Raised, Escalated, DeEscalated, and Ended messages of one alert share the same Alert Key, and alerts from several Base Monitors that push to the same integration never merge. Changes to the alert name, severity, description, or timestamps do not change the Alert Key. Messages without id or baseMonitorGuid are rejected.
Status and severity
An
Ended message carries severity None, so Flashduty uses previousSeverity (the severity before the alert ended) as the severity of the recovery event. An empty or unrecognized severity is treated as Warning. Messages whose messageType is not AlertNotification do not create alerts; Flashduty returns success for them.
Labels
The alert description is Redgate Monitor’s description of the alert type. For a custom metric with a secondary query, it also includes the detail text that query returns (
alertDetailText).
Troubleshooting
- The test message fails: Confirm that the Base Monitor machine can reach the Flashduty push URL, and configure the proxy as described above if one is required
- Flashduty returns a parameter error: Confirm that the URL is complete and includes
integration_key, and that the default message format is selected - An alert does not recover: Redgate Monitor sends a webhook 20 seconds after it receives an alert and retries once after 10 minutes if delivery fails. If both attempts fail, the message is lost and you need to close the alert in Flashduty manually. Each alert type also has a limit on how many notifications it can send for each monitored object in 24 hours (30 by default); raise it if alerts change often
- Alerts arrive with a delay: Webhook messages are sent about 20 seconds after the alert is raised, which is expected