Skip to main content
Notifications tell a person something happened. They never change what an agent can do. Settings › Notifications holds Destinations and the Built-in alerts: the three alerts Quint raises on its own, whatever your rules say. What your policy rules send (the refused-action alert, match thresholds and scheduled summaries) lives on the Alerts tab of Policies; see 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, and approval requests are set per workload on Workloads.

​
Destinations

Destinations is where alerts are delivered in real time: Slack, Microsoft Teams, PagerDuty, or your own webhook. A webhook takes a signed test delivery before it can be enabled; the three channels are verified when their credential is saved. If your workspace still has an older webhook from before alert channels existed, and no alert webhook channel, it is listed here read-only by its host, for example Webhook hooks.example.com, with the line “Older webhook — no status available. Replace it with a channel on Integrations.” It means alerts still go to that address, but Quint records no delivery status for it, so the dashboard cannot tell you whether messages arrive. Connect an alert webhook (or another channel) on Integrations to replace it: once the workspace has an alert webhook channel, alerts go to the channels and the older webhook is no longer listed or used.

​
Built-in alerts

Three alerts run on every event in your workspace. You do not write them and cannot delete them:
  • An agent said it would do one thing and did another. Quint compared what the agent said it was about to do with what it did, and the two differ. A serious one also opens an Incident under Incidents.
  • An agent did something unusual for this workspace. The action is out of line with what agents normally do here. It raises an alert and nothing more.
  • The risk score passed your limit. The action’s risk score reached the limit you set. It raises an alert and nothing more.
Each alert goes to every connected channel whose filter lets it through. To limit a channel to some alerts, or to turn a channel on or off, edit it on Integrations. Under the three alerts the page notes: “Security events — someone changed members, keys or settings — go only to the channels that have Send security events turned on.” followed by “Choose per channel:” and one link per connected channel, each opening that channel’s sheet on Integrations, where the Send security events switch is. Nothing about security events is set on this page.

​
The risk score limit

The limit is a number from 0 to 100. The row reads, for example, “Limit 70 of 100”; press change to edit it. While no limit is set the row reads “No limit set, so this alert is off.” and the risk-score alert never fires; Remove the limit turns it off again. For scale, the Sessions page counts a session as high risk from 70. The page says: “A Policy Writer, an Admin or an Owner can change the limit.” Every change is recorded in the admin audit log. Read members see the limit and cannot change it. For the exact condition behind each alert, see Technical details.

​
Workload notifications

Each workload has its own notification settings, set during setup or with Edit settings (Admin or Owner):
  • Approval requests: where a held tool call is sent for a decision.
  • Blocks: Don’t notify, All blocks or Only these categories.
  • Also send block notices to PagerDuty.
  • Channels, with Connect a channel if none exists yet.
A workload with no working channel cannot send approval requests. A workload with no approvers lets a held call wait until it expires; it is then denied. See Workloads.

​
What fires, and where it can go

​
Next