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 four destination types: Slack (native integration with OAuth and channel selection), Microsoft Teams (incoming webhook URL), Webhook (HTTP POST to any endpoint), and Email (a list of email addresses).

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, Webhook, or Email.

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. You can’t set User-Agent or X-CloudQuery-Signature: these headers are reserved for CloudQuery.
  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>"
}

Email destinations

Email destinations send each notification to a list of up to 20 email addresses.

Configuration

  1. Select Email from the Destination type dropdown.
  2. Type each address in Email addresses and press Enter, Space, a comma, or a semicolon after it. To add several at once, paste them separated by commas, semicolons, spaces, or line breaks.
  3. Click Save notification destination.

How email notifications work

Each address gets its own copy, so recipients do not see who else receives the email. Emails come from platform-notifications@cloudquery.io, with the sender name CloudQuery Platform.

The subject and body come from the rule that sends the email: a built-in subject and message, unless you edit the rule’s message content. Test emails and sync failure notifications always use the built-in subject and message.

CloudQuery does not ask recipients to confirm their address, and the emails have no unsubscribe link. Add only those addresses that expect these notifications. The footer of every email names your CloudQuery Platform host, such as platform.example.com, and tells recipients to ask an admin of that host to remove their address. To stop emails to an address, remove it from every email destination that lists it.

Test a destination

Click Send test notification to check that the destination 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. CloudQuery sends a test email to every address on an email destination. 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.

Emails are not arriving

CloudQuery cannot tell whether an email reached an inbox. A successful Send test notification means CloudQuery sent the email to at least one address, not necessarily to all of them. The recipient’s mail server can still reject the email or file it as spam.

  • Ask the recipient to check their spam or junk folder.
  • Ask the recipient’s mail administrator to allow mail from platform-notifications@cloudquery.io.
  • Check the recipient’s address on the destination for typos. If CloudQuery cannot send to any address, Send test notification reports an error that lists each one.

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