> ## Documentation Index
> Fetch the complete documentation index at: https://docs.quintai.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Alerts: refused actions, match thresholds and summaries

> What your policy rules send: the alert for a refused action, match thresholds on fixed UTC windows, and scheduled summaries, with where each one is sent and the exact rules behind the Alerts tab.

**Policies › Alerts** holds only what your policy rules send:

* **The refused-action alert**: "An AI agent tried something a rule refuses." It also opens an Incident.
* **Match thresholds**: a message when refuse matches reach a number you set within a fixed UTC window. They appear on the tab when match thresholds are active for your workspace.
* **Your scheduled summaries** (recaps): counts and rule names on a schedule.

Each one shows a read-only **Sent to** list: the channels it currently goes to. You turn a channel on or off, or connect a new one, on **Integrations**; the Alerts tab never changes a channel. An alert tells a person something. It never changes what a machine does.

Alerts that do not come from a rule live elsewhere. The three other built-in alerts (an agent said one thing and did another, unusual activity, and the risk score passing your limit) are on **Settings › Notifications**; see [Built-in alerts](https://docs.quintai.dev/settings/notifications.md#built-in-alerts). Security events (member, key and settings changes) are turned on or off per channel on **Integrations**, with each channel's **Send security events** switch. Approval requests are set per workload on **Workloads**; see [Workloads](https://docs.quintai.dev/dashboard/workloads.md).

Before you create a summary the tab reads "No summaries yet. A summary tells your team each week what the rules caught."

Looking for the exact rules and codes? See [Technical details](#technical-details) below.

## The refused-action alert

When an armed rule refuses an action, Quint sends "An AI agent tried something a rule refuses." to every channel listed under **Sent to**, and opens an Incident under **Incidents**. In shadow mode a rule records what it would have refused and does not refuse, so this alert stays quiet until enforcement is armed; see [Shadow enforcement](https://docs.quintai.dev/policies/shadow-enforcement.md). The alert itself has no setting: what reaches a channel is set on that channel's row on **Integrations**.

## What a recap is

A recap, shown on the tab as a scheduled summary, is a summary of policy activity sent to a Slack, Microsoft Teams or alert-webhook destination you already connected on **Integrations**. Destinations are picked, never created here; the builder links to Integrations when you need a new one. PagerDuty is not available for recaps.

Press **New summary**. The default is weekly, Monday 09:00, covering the last 7 days with the top 10 rules and no thresholds. The hour is in the timezone you choose; your browser's zone is offered first and is stored on the recap, so the schedule always reads in that zone. Cadence can be daily, weekly or monthly. The window can be 7, 14, 30 or 90 days, or **since the previous recap**. The right-hand pane previews the message in the chosen destination's format.

## What a recap contains

* **Posture**: seven counts for the window. Matches; would have asked; would have refused; refused; held; enforced with an unclassified outcome; unknown. Refuse matches are shown as their two parts, would have refused (shadow) and refused (armed).
* **Rules**: the top 5, 10 or 25 rules by matches, with each rule's would-refuse and refused counts, its trend, and how many rules were left out.
* **Thresholds**: each match threshold on the recap and how many times it was crossed.
* **Enforcement**: the workspace switch and each ruleset's serial and mode, labelled as the current configuration as of send time. It is not a history of what was armed during the window.
* One link back to the dashboard.

A recap never contains command text, file paths, prompts, hostnames or the names of people. Counts, rule names and families only. Long rule names are shortened and formatting is removed before sending.

Each count is compared with the period of equal length just before the window. When either period is incomplete no comparison is shown, rather than a misleading zero; a zero baseline reads "new".

## Windows and history

Windows are whole UTC calendar days, and the message states them, for example "1–14 Oct 2026, UTC days". Counts are as of send time: an event that arrives late is not added to a day already reported.

**Since the previous recap** starts where the last successful delivery stopped, up to 90 days; a longer gap is shortened and the message says so. The first delivery uses the cadence length.

Recap counts are kept for 400 days. Raw evidence, the individual matches under **Matches**, stays 14 days. The two periods are separate, so a 90-day recap sent soon after notifications arrive in your workspace shows an **available from** date rather than empty days, and no comparison until both periods have data. A recap's link opens that history as counts; **Matches** still shows only the last 14 days.

## Match thresholds

A threshold reads: alert after N refuse matches during each fixed UTC hour, 6-hour block, day or ISO week. A refuse match is a match a rule would have refused in shadow mode, or did refuse when armed. One action that matches several rules counts once per rule. The scope is all rules, one family or one rule; the builder shows the volume that scope saw in the last 14 days so you set N against real numbers. A recap holds up to 5 thresholds; none is preselected.

Windows are fixed, not rolling. Hours and 6-hour blocks are counted from 00:00 UTC, days start at 00:00 UTC and weeks start Monday 00:00 UTC. A threshold of 5 per hour with three matches at 10:58 UTC and three more at 11:02 UTC does not fire: the 10:00 hour saw three and the 11:00 hour saw three. The message names the window it covers.

A threshold fires when the count is reached, not at recap time, and goes to the recap's destination. A crossed threshold is a notification, not an incident: nothing is interrupted and nothing opens under **Incidents**. Editing a threshold starts its windows afresh. A recap that is switched off sends nothing, and its thresholds stop with it.

## Delivery

One message per period. If the destination fails, the same message is retried; the schedule and the "since previous" marker move only on a confirmed delivery. After three failed deliveries in a row the recap shows **degraded** with the last error class, and an Admin can retry. Delivery is retried, not exactly once: after an ambiguous timeout the same recap can arrive twice. If a destination is removed on Integrations, every recap bound to it is switched off and says why. After an outage, missed periods are sent newest first, at most three per recap.

**Send test** delivers the recap now, labelled as a test in the message. It does not move the schedule or the "since previous" marker, and it does not clear a failed scheduled delivery. One test per recap per minute, ten per workspace per hour.

## Who can do what

Every member can see recaps, their deliveries and the preview. Creating, editing, deleting and **Send test** need an **Admin** or **Owner** signed in to the dashboard, and each is recorded in the admin audit log. Limits: 20 recaps per workspace, 5 thresholds per recap.

> [!NOTE]
>
> Arming enforcement is separate from notifying about it. A recap reports what rules matched; it does not arm or disarm anything. See [Shadow enforcement](https://docs.quintai.dev/policies/shadow-enforcement.md).

## Technical details

The Alerts tab is written for security managers and keeps technical detail off the screen. Each of its sections links here. This section states, for a technical colleague, what each word on the tab is derived from.

### The refused-action alert, on the Alerts tab

| The tab says | Exact condition on the event | Severity | What else happens |
| - | - | - | - |
| An AI agent tried something a rule refuses. | `decision = BLOCK` | critical | Opens an Incident |

### The three built-in alerts, on Settings › Notifications

| The page says | Exact condition on the event | Severity | What else happens |
| - | - | - | - |
| An agent did something unusual for this workspace. | `confidence_band = ANOMALOUS` | high | Nothing more |
| An agent said it would do one thing and did another. | `action_type = DIVERGENCE_DETECTED` | The finding's own severity label: critical, high, medium or low. **high** when the label is missing or unreadable | Opens an Incident when the severity is critical |
| The risk score passed your limit of *n*. | `risk_score.composite ≥ your limit` | medium | Off while no limit is set |

All four rules run on Quint's side, against every event, in this order: refused action, unusual activity, said one thing and did another, risk score. Each is checked independently, so one event can raise more than one alert. The rules are fixed. The only parts you change are the risk score limit, on [Settings › Notifications](https://docs.quintai.dev/settings/notifications.md#built-in-alerts), and the channels alerts go to, on **Integrations**. In shadow mode a rule records and does not refuse, so the refused-action alert stays quiet until enforcement is armed; see [Shadow enforcement](https://docs.quintai.dev/policies/shadow-enforcement.md).

An alert goes to every enabled channel whose filter matches it. A channel can be limited to certain action types (`action_types`) or environments (`environments`); an empty filter means everything. Each list only narrows: an event with no environment never matches an environments list. When a channel is limited, **Sent to** says so in words next to the channel's name.

### How a channel's status under Sent to is decided

For each channel Quint records every delivery attempt: its time, the HTTP response code or an error class, the count of failures in a row since the last success, and the time and result of the last **Send test**. The **Sent to** list reduces these to one word. The word comes from one recorded state per channel, kept by Quint's alert sender. Nothing is read from a test result or from the absence of failures.

| Word on the tab | What Quint recorded |
| - | - |
| **Working** | The most recent message to the channel was accepted (an HTTP success code). It means the channel took the message, not that a person read it. |
| **Not working** | The most recent message was not accepted. The last response code or error class is on the channel's row on **Integrations**. Quint does not record when a run of failures started, so no date is shown. |
| **Not sending right now** | Quint's own alert sender is not running at the moment. Nothing is being delivered to any channel; sending resumes on its own when it is. |
| **Waiting for the first alert** | The channel is connected and nothing has needed sending yet. |
| **Turned off** | The channel is disabled on **Integrations**. |
| **Status not known yet** | Quint has no recorded state for this channel yet. |

### How a summary's "Last sent" is decided

Each due period of a summary creates one delivery job; **Send test** creates a job marked as a test and tests are excluded here. "Last sent" is read from the newest scheduled job:

* **Sent**: the job's state is `sent`; its delivery record carries the HTTP response code and the time the channel accepted it.
* **Failed**: the job's state is `failed`, shown with its error class, for example `timeout`, `rate_limited`, `http_5xx`, `credential_invalid` or `permanent`. The channel's raw response is never stored; a class and a bounded, redacted message are.
* **Not sent yet**: no scheduled job has run.

A failed job is retried with the same payload, with backoff, up to three attempts. After three failed deliveries in a row the summary shows as failed until a delivery succeeds; **Retry now** re-queues the failed job without resetting its count. The schedule and the "since previous" marker move only when a job reaches `sent`.

### Match thresholds

A threshold is `alert after N refuse matches during each fixed UTC window`, where the window is one hour, a 6-hour block, a day or a Monday-anchored week. A refuse match is a match on a rule whose disposition is refuse: one the rule would have refused in shadow mode, or did refuse when armed. The two parts are kept separate in every message. Windows are fixed, not rolling: hours and 6-hour blocks are counted from 00:00 UTC, days start at 00:00 UTC and weeks start Monday 00:00 UTC, so the 10:58 and 11:02 example under [Match thresholds](#match-thresholds) does not fire. Counting uses the time Quint received the event. A threshold fires when the count is reached, goes to its summary's channel, and never opens an Incident. Thresholds appear on the tab only when the feature is active for your workspace.

### Identifiers

For a support conversation, name the thing as the dashboard names it:

* A **channel** is identified by its name and type on the **Integrations** page. That row also shows its last test, its last error and its enabled state.
* A **summary's deliveries** are listed in its **Edit** view: each job's period, attempt number, response code, error class and time. Quote the period and the time of the delivery you are asking about.

## Next

* [How policies work](https://docs.quintai.dev/policies/how-policies-work.md)
* [Notifications and built-in alerts](https://docs.quintai.dev/settings/notifications.md), for the three alerts that do not come from a rule
* [Alerts and approvals in Slack, Teams and PagerDuty](https://docs.quintai.dev/integrations/alerts-in-slack-teams-pagerduty.md), to connect a destination
* [Webhooks and event fields](https://docs.quintai.dev/integrations/webhooks-and-event-fields.md), for a signed alert webhook


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.