Notifications

Notifications send CloudQuery Platform Insights and Policies to the tools your team already watches — a policy violation or a security finding becomes a Slack message, a Microsoft Teams message, or a web request.

Notifications have three distinct parts:

• Notification rules decide which resources go where. A rule matches resources by a condition and delivers them to a set of destinations or suppresses them.
• Notification destinations are the Slack channels, Teams channels, and webhook endpoints you define once and reuse across rules.
• Message content is the text or JSON body a rule sends to each destination, written as a Liquid template.

A rule sits between an insight and a destination, so one destination can serve many rules and one insight can route to different places depending on which resource is affected. A security finding on a production bucket can page #security-prod, but the same finding on a sandbox bucket can go nowhere.

How routing works

When an insight fires on a resource, the platform works through this sequence:

1. Silenced resources drop out. Silencing removes a resource before any rule sees it.
2. The insight’s own rules run, in order. The first rule whose conditions match the resource claims it, and either delivers it to that rule’s destinations or suppresses it. No rule below it is consulted for that resource.
3. Unclaimed resources fall through to the organization’s rules, which run the same way.
4. A resource no rule claims produces no notification.

A rule with no conditions matches every resource. Set the insight’s default from its Notification rules panel and the organization’s fallback under Settings > Organization > Insights. By default, no notification rules are configured on Insights so the organization defaults are used. See Defaults for how to configure either one.

Suppress exists so a narrow exception can sit above a broad rule without rewriting it. For example: A rule that sends every production finding to #security-prod stays as it is; a suppress rule above it, matching the one app you do not want paged about, carves that app out.

Notification lifecycle

Rules are evaluated after each sync completes, and again immediately after you change a policy.

CloudQuery Platform tracks which resources each rule has already sent a notification about, so a resource that keeps violating does not produce a notification every cycle:

• A resource a rule matches for the first time produces a triggered notification.
• A resource that keeps matching produces nothing further.
• A resource that stops matching is recorded as resolved. When a rule’s last matching resource clears, the rule sends one resolved notification. If the insight still has violations, no resolved notification is sent — the resource was silenced or re-routed.
• A resource that violates again after being resolved produces another triggered notification.

Notifications are batched per rule per evaluation: one message carrying the newly matching resources.

Delivery

Deliveries are queued and are retried. See Webhook receivers for the retry schedule, signature verification, and the payload contract.

Slack and Microsoft Teams messages carry the rendered text of the rule’s content. Webhooks carry a JSON body.

Next steps

• Notification rules — create rules, write conditions, and order them
• Message content — write the message with Liquid templates
• Webhook receivers — the payload schema and signature verification
• Notification destinations — connect Slack, Microsoft Teams, and webhook endpoints