Policies

You have ten rules across three teams. Each team wants their incidents in their own Slack channel during work hours, and you want every critical incident to also page the on-call rotation. You don't want to encode "which channel?" in every rule. Policies are the routing layer that handles that separation.

What a Policy is

A Policy is a named bundle of channels with one delivery mode, an optional time window, and a per-day cap on notifications. A Rule references one Policy; the Policy decides what to do with every incident the Rule produces.

The model is intentionally thin. There is no per-rule channel override, no per-severity routing, no escalation ladder. One Rule → one Policy → one or more Channels.

The fields

• Name — short, descriptive. "On-call · Critical infra", "Finance · Budgets", "Platform · Weekly digest".
• Channels — one or more channel references. The channels you can pick from come from your tenant's configured channel list. In-app delivery is handled by the delivery mode, not by selecting a channel — see below.
• Delivery mode — immediate, daily_digest, or in_app_only.
• Time window — optional start hour, end hour, and timezone. Outside the window, incidents queue and deliver at the next window open.
• Daily cap (cap_per_day) — maximum notifications per day. When the cap is hit, additional incidents roll into a digest the next morning. Default 20.

A Policy can also be deleted only when no Rules reference it. The delete dialog tells you how many Rules would be affected.

Delivery modes

Three modes, each answering a different question:

in_app_only is the reason the channels field can be empty. When the mode is in-app-only, the alert appears in the Smart Alerting inbox in the dashboard and nothing goes out to Slack, email, or webhook. Channels are not required and the editor gates them off.

For immediate and daily_digest, at least one channel is required.

Time windows and quiet hours

A time window restricts delivery to a contiguous range of hours in a named timezone. Outside the window, incidents queue and deliver at the next window open.

Configure with:

• Start hour — 0–23, on the hour.
• End hour — 0–23, on the hour. Must be later than start.
• Timezone — UTC, America/New_York, America/Los_Angeles, Europe/London, Europe/Berlin, Asia/Tokyo. (Add more in your tenant's timezone settings.)

A 09:00–17:00 America/New_York window means notifications fire between 9 AM and 5 PM Eastern. A 5 PM incident on Friday queues and delivers at 9 AM Monday.

Daily cap

cap_per_day is a guardrail against noisy days. Once a Policy delivers its cap, further incidents from any Rule linked to that Policy roll into a single end-of-day digest. The cap resets at midnight UTC.

Defaults to 20. Set it higher for high-traffic Policies (e.g., a paging Policy that you want uncapped — set to 9999). Set it lower for digest Policies you want to always batch (e.g., a 1-per-day informational digest).

Channels on a Policy

A Policy can fan out to multiple Channels. Three Slack channels and an email distribution list? List all four; every notification goes to all four. The fan-out is parallel — slow delivery on one channel doesn't block the others.

Channels referenced by a Policy must exist in your tenant's channel list before the Policy is saved. The editor's "Add a new channel" shortcut opens the Channel editor inline so you can create the destination without losing your Policy draft.

How rules use policies

A Rule has a policy_id field that references one Policy. When an incident fires, Kubeadapt looks up the Policy, then dispatches to every Channel on the Policy via the delivery mode and time-window rules.

You can change a Rule's Policy reference at any time. The change takes effect on the next incident; existing in-flight notifications respect the Policy that was active when they were dispatched.

Reusing a Policy across many Rules is the recommended pattern. A "Platform · On-call" Policy can carry every Rule that should reach the on-call channels, and an "Engineering · Daily digest" Policy can carry every informational rule. Add or remove channels in one place and every Rule's routing updates.

Order of evaluation

There is no priority or fallback evaluation in v1. Each Rule → one Policy → fan out. If you want a critical alert to reach two destinations, list both Channels on the same Policy. If you want different urgency for different alert types, create two Rules with the same scope, route each to a Policy with the appropriate channels and delivery mode.

When a Policy is the wrong layer

A Policy is per-Rule. If two teams in the same scope want different channels for the same alert type, you need two Rules with two Policies. The Rules can be identical except for the Policy reference. This is verbose, but it preserves the "one Rule, one Policy" simplicity.

If you find yourself maintaining many parallel Rules to satisfy different teams' routing preferences, talk to the Kubeadapt team — that's the case to surface for the next iteration of the routing model.

What's not here

• No severity-based routing. Every incident from a Rule goes to every Channel on the Policy. To split by severity, split into two Rules with two Policies.
• No escalation ladder. No "page on-call after 15 minutes if not acknowledged." Acknowledgement is tracked on the incident; escalation is a manual handoff today.
• No exclusions. A Policy fires on every incident from every Rule that references it. No "exclude this namespace" filter at the routing layer — push that filter up to the Rule's scope instead.

Next steps

• Channels — the destinations a Policy fans out to.
• Rules — what a Policy is routing for.
• Overview — how the pieces fit together.