Skip to main content

Notification Configuration: Alerts for Policy Violations and Escalations

Notifications are only useful when they match the operating model of the people receiving them. Keeptrusts treats the in-app inbox as the canonical alert surface, exposes it directly at /inbox from the top-bar bell, and lets users add optional email mirroring, quiet hours, and category-based opt-outs from Settings → Notification Preferences. That means your team can keep urgent governance signals visible without turning every non-critical event into noise.

Use this page when​

  • You want escalations, gateway issues, and spend signals to reach the right operators without constant manual checking.
  • You need to tune notification delivery for different types of users.
  • You want a practical alert workflow that starts in the inbox and lands people in the exact surface that needs action.

Primary audience​

  • Primary: Technical Engineers
  • Secondary: Team leads, reviewers, platform administrators

The problem​

Most alerting systems fail in one of two ways. Either they are so quiet that important issues are discovered late, or they are so noisy that teams stop trusting them. AI governance creates exactly the kind of signals that can drift into both extremes: escalations, gateway failures, budget thresholds, task completions, long-running chat responses, collaboration changes, and security notices all matter, but they do not all matter in the same way.

If every event becomes an email, people ignore the inbox. If every event is in-app only, people miss issues while away from the console. If quiet hours suppress too much, urgent review items wait until morning. If categories are not separated, a reviewer who needs escalation alerts may still get flooded by lower-value completion notices.

Keeptrusts solves that by treating notifications as an operator workflow, not a generic message stream.

What the feature does​

The notification system has two layers.

The first is the inbox itself. The bell in the top navigation leads to /inbox, where users can review notifications, filter by category, open detail views, and follow deep links back to the source surface. Escalations can take you into the review path. Approval items can take you into the approvals view. Long-running chat completions can take you back into the relevant chat session. Other notifications can point to tasks, connectors, knowledge assets, gateways, exports, or settings pages.

The second layer is preferences. In Settings → Notification Preferences, users can:

  • keep in-app delivery on as the baseline channel,
  • enable optional email mirroring,
  • define quiet hours,
  • opt out of selected categories.

The current categories cover the main operational workloads:

  • escalations
  • system
  • security
  • billing
  • task completions
  • chat completions
  • sharing and collaboration
  • agent lifecycle
  • gateway lifecycle

That separation matters because the person who owns escalation review is not always the same person who cares about task-run completions or sharing updates.

Keeptrusts also handles urgency sensibly. Quiet hours suppress non-critical notices, but critical categories such as escalations and security are designed to bypass those quiet periods so the platform does not become silent when something actually needs immediate review.

Practical workflow​

The best way to configure notifications is to start from the operator’s job, not from the full category list.

Imagine a team lead who owns policy review during business hours and needs to be warned about serious issues after hours without being woken up for every chat completion.

Use this setup flow:

  1. Open the top-bar bell and inspect the current inbox so you know what kinds of events are already arriving.
  2. Go to Settings → Notification Preferences.
  3. Leave in-app delivery as the default channel.
  4. Enable email mirroring if the user needs alerts away from the console.
  5. Turn on quiet hours for non-critical notifications, for example 22:00 to 08:00 in the user’s actual timezone.
  6. Keep Escalations and Security enabled because those are the categories most likely to require immediate response.
  7. Opt out of lower-value categories for that user if they create noise, such as task completions or chat completions.
  8. Save the preferences.
  9. Trigger a test event, such as a dev-environment escalation or a long-running chat completion, and confirm the expected inbox behavior.

That is a much better pattern than leaving every user on the same default configuration forever.

A concrete example​

Suppose your organization runs a shared reviewer rotation for governance exceptions. Reviewers need prompt notice when a high-severity escalation lands, but they do not need an email every time a background chat response finishes or a collaboration permission changes.

In that case, the reviewer should keep escalations enabled, allow email mirroring, and set quiet hours for non-critical events. A product engineer working mostly in the console might choose the opposite: inbox only, no email mirror, and opt-outs for several categories because they already monitor the product during the day.

The key is that both users still rely on the same canonical inbox. Email mirror is optional and supportive, not a separate source of truth. That reduces the “which alert did you see?” confusion that happens when every channel behaves differently.

The deep-linking behavior is what makes the system operationally useful. A notification should not just say something happened. It should take the user to the right workbench, review view, or resource page so action can begin immediately.

What to test after configuration​

Notification settings should be validated the same way you validate policy changes: with a short scenario list.

Test at least these cases:

  • an escalation created from a governed chat or policy decision,
  • a gateway lifecycle event such as drift or connectivity change,
  • a billing or usage signal,
  • a long-running chat completion,
  • an export completion if your operators use evidence packages.

When you test, confirm three things.

First, the event appears in the inbox.

Second, the notification opens the correct follow-up surface.

Third, the delivery behavior matches the preference set. If email mirroring is on, confirm it occurs for eligible notifications. If quiet hours are active, confirm non-critical events are deferred while critical ones still break through as designed.

It is also worth remembering one implementation boundary: the inbox is managed in the console, not from a CLI notification command. That keeps notification triage anchored to the same review surfaces it supports.

Results and impact​

Well-configured notifications improve response quality more than response speed alone. The right operator sees the right signal and lands in the right page with less hunting. Escalation owners stop polling review queues. Platform operators can respond to gateway issues before they become widespread complaints. Teams can let long-running chat tasks finish in the background without babysitting the workbench.

The bigger win is organizational clarity. Once the inbox becomes the canonical surface and preferences are tuned per role, users stop arguing about whether they should watch email, a dashboard, or a queue. They know the operating path: receive the alert, open the inbox detail, follow the link, act in the source surface.

That is the difference between a notification feature and a reliable operations loop.

Key takeaways​

  • Keeptrusts uses the in-app inbox at /inbox as the canonical notification surface.
  • Email mirroring is optional and should support, not replace, inbox-driven triage.
  • Quiet hours reduce noise, but critical categories such as escalations and security still matter most.
  • Category opt-outs should reflect the user’s actual operating role.
  • Test the deep links after configuration so alerts take people to the right place to act.

Next steps​