Develop

redirects.mjs

@@ -23,7 +23,24 @@ export const redirects = {
   '/azure-monitoring': '/azure-integration/',
   '/configuration': '/kloudmate-agent/management/',
   '/database-integrations': '/database-monitoring/',
-  '/direct-database-monitoring': '/database-monitoring/direct-database-monitoring/',
+  '/database-monitoring/database-activity-monitoring-dam': '/kloudmate-agent/ebpf-observability/',
+  '/database-monitoring/database-activity-monitoring-dam/ml-classifier-deployment-guide':
+    '/database-monitoring/sensitive-data/',
+  '/database-monitoring/database-integrations/mongodb-monitoring':
+    '/kloudmate-agent/database-monitoring/engines-and-coverages/',
+  '/database-monitoring/database-integrations/mssql-monitoring':
+    '/kloudmate-agent/database-monitoring/engines-and-coverages/',
+  '/database-monitoring/database-integrations/mysql-monitoring':
+    '/kloudmate-agent/database-monitoring/engines-and-coverages/',
+  '/database-monitoring/database-integrations/oracledb-monitoring':
+    '/kloudmate-agent/database-monitoring/engines-and-coverages/',
+  '/database-monitoring/database-integrations/postgresql-monitoring':
+    '/kloudmate-agent/database-monitoring/engines-and-coverages/',
+  '/database-monitoring/database-integrations/redis-monitoring':
+    '/kloudmate-agent/database-monitoring/engines-and-coverages/',
+  '/database-monitoring/direct-database-monitoring': '/kloudmate-agent/database-monitoring/overview/',
+  '/database-monitoring/opentelemetry-database-monitoring': '/apm-and-tracing/auto-instrumentation/',
+  '/direct-database-monitoring': '/kloudmate-agent/database-monitoring/overview/',
   '/enable-service-principal-azure': '/azure-integration/enable-service-principal-azure/',
   '/get-help': '/getting-started/get-help/',
   '/go-instrumentation-running-on-kubernetes': '/kloudmate-agent/auto-instrumentation/go/',
@@ -35,8 +52,7 @@ export const redirects = {
   '/managing-kloudmate-agents': '/kloudmate-agent/management/',
   '/managing-panels': '/visualize-data/dashboards/managing-panels/',
   '/mcp-integrations': '/kloudmate-assistant/mcp-server/',
-  '/ml-classifier-deployment-guide':
-    '/database-monitoring/database-activity-monitoring-dam/ml-classifier-deployment-guide/',
+  '/ml-classifier-deployment-guide': '/database-monitoring/sensitive-data/',
   '/net-instrumentation-running-on-kubernetes': '/kloudmate-agent/auto-instrumentation/dotnet/',
   '/setting-up-kloudmate': '/getting-started/setting-up-kloudmate/',
   '/sns': '/incident-management/integrations/integrating-with-aws-cloudwatch/',

src/content/docs/docs/alerts/alert-groups.mdx

@@ -7,8 +7,6 @@ sidebar:
 
 When related alerts fire close together, KloudMate groups them into a single **Alert Group**. Instead of notifying on every individual alert, you get one notification for the group, and new alerts append to it rather than fan out into separate notifications.
 
-A group survives restarts and deduplicates against the same incident over time, so a recurring issue keeps showing up on the same group rather than spawning a fresh one each time.
-
 ## How groups form
 
 An Alert Group forms by static grouping or by the AI correlation engine. Both produce the same kind of group:
@@ -20,63 +18,65 @@ You choose the mode per routing rule; see [Routing Rules](../routing-rules/#aler
 
 ## Where to find groups
 
-Open **Alerts → Alert groups** in the left navigation. This is the workspace-wide view of every group, open or resolved.
+Open **Alerts**, which starts on the **Groups** tab: the workspace-wide view of every group, firing or resolved.
+
+![The Groups tab: the All, Firing, and Resolved filter, the Routing rule filter, the search box, and the group list](./images/alert-groups-list.png)
 
-![Alert Groups list](./images/alert-groups-list.png)
+Above the list, a summary shows how many groups are firing and how many are resolved, such as **6 Firing, 130 Resolved**.
 
-Columns: **Group** (title), **State** (Open / Resolved), **Instances** (the firing-instance count), **Opened**, **Last update**, and an RCA indicator when an investigation is attached (a manual **Run RCA** or [Auto-RCA](../auto-rca/)).
+Columns: **Group** (title), **State** (**Firing** or **Resolved**), **Severity**, **Instances** (the number of unique instances in the group), **Opened**, **Last update**, and **RCA** when an investigation is attached (a manual **Run RCA** or [Auto-RCA](../auto-rca/)).
 
-Expand any row to preview that group's alerts inline: alert name, state, severity, received time, and labels, without leaving the list. The group title links straight to the full detail page.
+Expand any row to preview that group's alerts inline, with each alert's state, instance counts, and when it was last seen. The group title links straight to the full detail page.
 
 Filter the list by:
 
-- **State:** All / Open / Resolved toggle. Defaults to **Open**.
-- **Routing rule:** dropdown filtered to rules in the workspace.
-- **Label matchers:** filter by `key=value`.
+- **State:** **All**, **Firing**, or **Resolved**. Defaults to **Firing**.
+- **Routing rule:** a single rule, or **All routing rules**.
+
+To find a group by title or by a label such as `service=api`, use the search box. On the **Resolved** and **All** filters, the search matches titles only.
 
-Severity isn't a filter on the list. It lives on the per-instance alerts inside a group, not on the group itself.
+Severity isn't a filter on the list.
 
 ## Anatomy of a group
 
 A group carries:
 
-- **Title:** set by the first alert that opened the group, and **immutable** afterward, even if a higher-severity alert joins later.
-- **State:** `Open` while at least one underlying instance is firing; `Resolved` once everything quiets. A firing group whose instances are **all silenced** stays `Open` but carries a **Muted** badge. Muting gates notifications; it doesn't resolve the group.
+- **Title:** for a **Static** group, the rendered **Title** annotation when every instance that opened the group renders the same text, and otherwise the name of the alert that opened it. The correlation engine names an **Auto (AI)** group. See [Set a custom notification title](../annotations-and-severity/#set-a-custom-notification-title).
+- **Severity:** the most severe **Severity** annotation among the instances that opened the group.
+- **State:** **Firing** while at least one underlying instance is firing, and **Resolved** as soon as none is. A firing group whose firing instances are **all silenced** stays **Firing** and is marked **Muted**. Muting gates notifications; it doesn't resolve the group.
 - **Labels:** the labels that define the group, read from the alerts that joined it (the group-by keys, in Static mode).
 - **Alerts and instances:** how many distinct alerts and firing instances the group holds so far.
 - **Routing rule:** the rule that opened the group.
 - **Group ID:** the durable identifier you can share with teammates or paste into the assistant.
 - **Correlation reason:** for an Auto-correlated group, why these alerts were grouped. See [Why these were grouped](#why-these-were-grouped).
 - **Investigation:** a root-cause investigation, when one is attached. Start it manually with **Run RCA**, or automatically with [Auto-RCA](../auto-rca/); see [Run RCA and View RCA](#run-rca-and-view-rca).
 
-Severity isn't a single group-level field. Each underlying instance carries its own severity.
-
 ## Group detail
 
-Click any row to open the group detail page.
+Click a group's title to open its detail page.
 
-![Alert Group detail](./images/alert-group-detail.png)
+![Alert group detail page: the Run RCA, Ask Assistant, and Silence this group buttons above the Instances panel](./images/alert-group-detail.png)
 
 ### Header
 
-- **Title:** set by the first alert and can't be changed.
+- **Title:** named from the alerts that opened the group. See [Anatomy of a group](#anatomy-of-a-group).
 - **Run RCA / View RCA:** starts or opens a root-cause investigation for the group. See [Run RCA and View RCA](#run-rca-and-view-rca).
-- **Ask KloudMate Assistant:** opens the assistant chat panel with the group's labels, state, alert and instance counts, and routing rule pre-loaded into the prompt, so you can start investigating without retyping context.
+- **Ask Assistant:** opens the assistant chat panel with the group's labels, state, alert and instance counts, and routing rule pre-loaded into the prompt, so you can start investigating without retyping context.
 - **Silence this group:** opens the silence creator with matchers derived from the group, bound to the group so the silence lifts when the group resolves. The binding sets when the silence ends, not what it mutes: the silence covers any alert in the workspace whose labels match its matchers, group member or not. See [From an Alert Group](../silences/#from-an-alert-group).
 
-### Firing instances
+### Instances
 
-The **Firing instances** panel is a table of the unique alert instances that joined this group, deduplicated by the per-instance labels the grouping engine uses.
+The **Instances** panel lists the unique alert instances in this group. Filter it by **All**, **Firing**, or **Resolved**; it shows **Firing** instances by default.
 
 - **Common labels:** labels shared by every instance, so the per-row labels column only shows what varies.
 - **Columns:**
-  - **State:** the instance's current state: **Firing**, **No Data**, **Error**, or **Resolved**. Silenced instances are flagged as muted, so you can see at a glance which ones are firing but suppressed.
+  - **State:** **Firing** or **Resolved**. Instances muted by a silence or maintenance window are also marked **Muted**, so you can see at a glance which ones are firing but suppressed.
+  - **Value:** the last evaluated value behind the instance's state.
   - **Alert:** the alert rule name. Links to the rule when the alert is KloudMate-native (carries an `alarm_id` label).
   - **Instance labels:** the labels that distinguish this instance from its siblings (common labels are stripped out).
-  - **Severity:** the per-instance severity, if the alert carries one.
   - **Since:** how long this instance has been in its current state.
 
-Use this panel to see what's firing inside the group at a glance. For example, service A's `prod` and `staging` are firing while `dev` has already recovered.
+Use this panel to see what's firing inside the group at a glance. Switch to **All** to see, for example, that service A's `prod` and `staging` are firing while `dev` has already recovered.
 
 ### Run RCA and View RCA
 
@@ -91,10 +91,12 @@ This is the manual trigger. To investigate every group a rule opens automaticall
 
 ### Tabs
 
-- **Alerts:** every underlying alert as a row. Columns: Alert (linked to the rule when available), State, Severity, Received at, Labels. Use this when you need the raw event-by-event stream rather than the instance-level rollup.
+- **Alerts:** one row per alert rule in the group, with its state, how many of its instances are firing, and when it was last seen. The alert name links to its rule when the alert is KloudMate-native.
 - **Blast radius:** what the group's firing resources connect to. See [Blast radius](#blast-radius).
-- **Audit:** a timeline of everything that happened to the group: opened, alerts appended, silence applied, notification dispatched, resolved. For Auto-correlated groups, it also logs when the engine opened the group and when it correlated each alert.
-- **Notifications:** per-channel dispatch outcomes (ok / failed / suppressed-by-silence), with deep links to where the notification landed: Slack thread URL, Jira ticket, KloudMate Incidents incident, and so on.
+- **Audit:** a timeline of the group's history, from when it opened to when it resolved. It records each notification and reminder sent, notifications suppressed by a silence or skipped, and investigations. For Auto-correlated groups, it also logs when the engine opened the group and when it correlated each alert.
+- **Notifications:** every notification sent for the group, reminders included, with each channel's result and a link to where it landed: the Slack thread, the Jira ticket, the KloudMate Incidents incident, and so on.
+
+![Reminder on an alert group Audit tab](./images/alert-group-audit-reminder.png)
 
 ### Blast radius
 
@@ -110,7 +112,7 @@ The same graph appears on a single alert's **Blast radius** tab and on a resourc
 
 **Why these were grouped** gives the reason in plain English, the shared labels, and supporting detail.
 
-This reason appears only when the engine correlated more than one alert. A lone alert the engine left on its own has none, which is expected (see [Cold start](#cold-start)).
+This reason appears only when the engine grouped more than one alert instance, either several alerts or the same alert firing on multiple targets. A lone instance the engine left on its own has none, which is expected (see [Cold start](#cold-start)).
 
 ### Cold start
 
@@ -124,7 +126,7 @@ Choosing **Wrong** lets you point at the specific alert that doesn't belong, or
 
 ## When a group resolves
 
-KloudMate marks a group `Resolved` once every underlying instance has resolved and a short grace period for flapping has elapsed (a few minutes, long enough to absorb instances that flap rapidly without closing the group prematurely). Resolved groups stay in the list under the **Resolved** filter and remain searchable indefinitely.
+KloudMate marks a group **Resolved** as soon as none of its instances is firing. If a matching alert fires again after that, it opens a new group. Resolved groups stay in the list under the **Resolved** filter.
 
 ## Related
 

src/content/docs/docs/alerts/alert-lifecycle.mdx

@@ -8,7 +8,7 @@ sidebar:
 
 import { LinkCard, CardGrid } from '@astrojs/starlight/components';
 
-Once you've [created an alert](../create-alerts/), KloudMate evaluates it on a schedule and moves it through a series of states. The control knobs in **Configure evaluation settings** (**Evaluate every**, **Pending duration**, **Recovery period**, **Alert state if No data**, and **Alert state if Error**) each shape *when* and *how* those transitions happen.
+After you've [created an alert](../create-alerts/), KloudMate evaluates it on a schedule and moves it through a series of states. The control knobs in the rule's evaluation settings (**Evaluate every**, **Pending duration**, **Recovery period**, **Alert state if No data**, and **Alert state if Error**) each shape *when* and *how* those transitions happen.
 
 This page explains the full lifecycle: why an alert can fire instantly, and why No Data and Error don't wait out the pending duration.
 
@@ -76,21 +76,23 @@ A **re-breach during Recovering** snaps the instance back to **Firing** without
 
 ## The control knobs at a glance
 
-| Knob (form label) | What it controls | Default | Inherits from [folder](../folders/)? |
+| Knob (form label) | What it controls | When blank | Inherits from [folder](../folders/)? |
 |---|---|---|---|
 | **Evaluate every** | How often the rule runs. | `60s` | Yes |
 | **Pending duration** | How long a breach must hold before **Firing**. | Fire immediately | No (per rule) |
 | **Recovery period** | How long a clear must hold before resolving. | Resolve immediately | No (per rule) |
 | **Alert state if No data** | Which state a no-data result becomes. | No Data | Yes |
 | **Alert state if Error** | Which state an error result becomes. | Error | Yes |
 
+The **When blank** values apply when neither the rule nor its folder sets a value. New rules are pre-filled with **Evaluate every** set to `1m`, **Alert state if No data** set to **No Data**, and **Alert state if Error** set to **Firing**.
+
 ## How No Data and Error fit in
 
 No Data and Error behave differently from a threshold breach. A common question:
 
 > *I configured the same query, pending duration, and recovery period. Only the **Firing** state goes through the pending and recovery windows; **No Data** and **Error** don't. Is that expected?*
 
-**Yes, that's expected.** The **Pending duration** and **Recovery period** are properties of the *firing episode*. They gate the ramp **into** and **out of** Firing. **No Data** and **Error** are separate evaluation outcomes. By default they aren't part of a firing episode, so there is nothing for those windows to debounce. An instance switches into (and out of) No Data or Error **immediately**.
+**Yes, that's expected.** The **Pending duration** and **Recovery period** are properties of the *firing episode*. They gate the ramp **into** and **out of** Firing. **No Data** and **Error** are separate evaluation outcomes. Unless you map them to **Firing**, they aren't part of a firing episode, so there is nothing for those windows to debounce. An instance switches into (and out of) No Data or Error **immediately**.
 
 What each setting does on a no-data or error result:
 
@@ -105,14 +107,16 @@ What each setting does on a no-data or error result:
 
 **Alert state if Error**
 
+New rules start with this set to **Firing**. **Error** applies when the field is blank and the folder doesn't set it.
+
 | Target | Behavior when the evaluation errors |
 |---|---|
-| **Error** (default) | Instance switches to **Error** immediately. No pending wait, no recovery wait. |
+| **Error** | Instance switches to **Error** immediately. No pending wait, no recovery wait. |
 | **Normal** | Instance switches to **Normal** immediately, treated as a clear (so a firing instance enters the Recovery period). |
 | **Firing** | Treated exactly like a threshold breach: it ramps through the **Pending duration**, and honors the **Recovery period** when the query recovers. |
 
 :::note[The takeaway]
-If you want a no-data or error condition to be **debounced by the same Pending duration and Recovery period as a threshold breach**, set **Alert state if No data** / **Alert state if Error** to **Firing**. Left on their default (**No Data** / **Error**), they're immediate and deliberate: a gap or a broken query shows up right away rather than waiting out a timer.
+To debounce a no-data or error condition with the same **Pending duration** and **Recovery period** as a threshold breach, set **Alert state if No data** or **Alert state if Error** to **Firing**. Set to **No Data** or **Error**, they switch immediately, so a gap or a broken query shows up right away instead of waiting out a timer.
 :::
 
 :::tip
@@ -121,7 +125,7 @@ Infrastructure failures (a query timeout, an unreachable source, or any error th
 
 ## Other behaviors you might notice
 
-- **Transient blips on a firing alert.** A firing instance only *rides through* a momentary No Data or Error gap when that state is mapped to **Firing**. If No Data / Error are left on their defaults, a firing instance switches to **No Data** / **Error** on the next bad evaluation; it does not stay "Firing" through the gap.
+- **Transient blips on a firing alert.** A firing instance only *rides through* a momentary No Data or Error gap when that state is mapped to **Firing**. If No Data or Error is mapped to its own state, a firing instance switches to **No Data** or **Error** on the next bad evaluation; it does not stay "Firing" through the gap.
 - **A series that disappears entirely.** When a whole series stops appearing in the query results (a host is decommissioned, a metric is dropped), KloudMate waits a short grace window (about **two evaluation intervals**) and then treats the vanished instance as resolved and closes it. This is distinct from **No Data**, which is the query *running* and returning nothing. To alert on the disappearance instead of closing it quietly, turn on [Instance Absence Detection](../instance-absence-detection/).
 - **Multi-instance rules.** A rule's overall state reflects its instances: if any instance is firing (or recovering), the rule reads as **Firing**; otherwise it surfaces the most significant instance state. Each instance still runs its own lifecycle independently.
 - **Silences and maintenance windows don't change state.** They gate the outbound *notification*, not the lifecycle. A silenced instance keeps evaluating and transitioning, and its state changes still land in history; only the notification is withheld. See [Silences](../silences/) and [Maintenance Windows](../maintenance-windows/).