Skip to Content
PlatformFeaturesNotificationsNotification Destinations

Notification destinations

Notification destinations define where CloudQuery Platform sends notifications when policy violations are detected or an insight matches a notification rule. There are three destination types: Slack (native integration with OAuth and channel selection), Microsoft Teams (incoming webhook URL), and Webhook (HTTP POST to any endpoint).

A destination is connected once and reused. Notification rules decide which insights reach it and what each message says, so you do not need a separate destination per message.

Create a notification destination

  1. In the sidebar, click your user icon and select Organization settings.
  2. Open the Notification destinations section.
  3. Click Add notification destination.
  4. Enter a Destination name to identify this destination in notification rules (e.g., “Slack - Security Channel” or “PagerDuty Webhook”).
  5. Select a Destination type: Slack, Microsoft Teams, or Webhook.

The fields that follow depend on the type you select.

Slack destinations

The Slack destination type connects to your Slack workspace via OAuth and sends notifications directly to selected channels. No webhook URL is required.

Configuration

  1. Select Slack from the Destination type dropdown.
  2. Click Connect workspace to start the OAuth flow. A new window opens where you authorize CloudQuery to post to your Slack workspace.
  3. After authorization, select one or more channels from the Slack channels dropdown.
  4. Click Save notification destination.

How Slack notifications work

CloudQuery posts each notification to every selected channel. The text comes from the rule that sends it: a built-in message, unless you edit the rule’s message content.

Microsoft Teams destinations

Microsoft Teams destinations post to a channel through an incoming webhook URL.

Configuration

  1. Select Microsoft Teams from the Destination type dropdown.
  2. Set the Microsoft Teams Webhook URL. Create one in Teams with a workflow or an incoming webhook connector.
  3. Click Save notification destination.

The URL is stored encrypted and is not shown again after saving. To change it, enter a new one.

Webhook destinations

Webhook destinations send an HTTP POST request to any URL you specify. Use this type for services like PagerDuty, Opsgenie, or custom HTTP endpoints.

Configuration

  1. Select Webhook from the Destination type dropdown.
  2. Set the Destination URL: the HTTP(S) endpoint to receive notifications.
  3. If your endpoint needs HTTP headers, such as Authorization, click New header under HTTP Headers to add each one. CloudQuery sends Content-Type: application/json by default.
  4. If you want your receiver to check that requests come from CloudQuery, set a Signing secret of at least 16 characters under Webhook signing. CloudQuery then signs every delivery to this destination with an X-CloudQuery-Signature header. See Webhook receivers for how to verify it.
  5. Click Save notification destination.

The signing secret is stored encrypted and never returned. Leave the field blank when editing to keep the existing secret, or enter a new one to replace it.

Notification rules define the content sent to notification destinations. See Message content.

Example: Slack incoming webhook

To post through a Slack Incoming Webhook instead of the native Slack integration, create a Webhook destination with the incoming webhook URL. Then, in each rule that delivers to it, click Edit body on its row and write the Slack payload as a Liquid template:

{
  "text": "*{{ event.status }}*: {{ insight.title }}\nSeverity: {{ insight.severity }}\n<{{ insight.url }}|View in CloudQuery>"
}

Test a destination

Click Send test notification to check that the endpoint is reachable. Webhook destinations receive a test request, signed if the destination has a signing secret. Slack and Microsoft Teams destinations receive a test message. To check what a rule sends, use Preview in its content editor.

Manage destinations

Notification destinations are shared across every notification rule. You can:

  • Edit a destination’s configuration at any time
  • Delete a destination (rules using it stop sending to that endpoint)
  • Reference the same destination from any number of rules, each with its own message content

Note: The destination type cannot be changed after creation. To switch types, create a new destination.

Troubleshooting

Notifications are not being received

  • Verify the destination URL is reachable from the CloudQuery Platform server (webhook destinations only).
  • Use the Send test notification button to confirm the endpoint responds.
  • A resource that keeps violating produces one notification, not one per sync. See Notification lifecycle.

Slack connection failed

  • Verify that the Slack integration is configured for your CloudQuery Platform instance. If you see “Slack integration is not configured,” contact your administrator.
  • Make sure you authorized CloudQuery in the correct Slack workspace.
  • If channels are not appearing in the dropdown, confirm the workspace connection completed and refresh the page.

Destination cannot parse the request body

Webhook notifications are always JSON.

  • If the receiving service expects different fields, click Edit body on the destination’s row in each rule that delivers to it, as in the Slack incoming webhook example.
  • If you added your own Content-Type header, set it to application/json or remove it.
  • Policies: configure notifications for policy violations

Programmatic access

Notification destinations can be managed via the Platform API. See the Platform API Reference (alerts section) for endpoint details.

Next steps

  • Notification rules — route insights by account, tag, app, environment, or owner
  • Policies — monitor compliance and trigger notifications on violations
  • Reports — schedule reports with notifications
Was this page helpful?

Last updated on

OverviewNotification Rules