Develop

.github/CODEOWNERS

@@ -0,0 +1 @@
+* @amitava82

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

@@ -130,7 +130,7 @@ Each tab shows how many items it holds, such as **Instances (7)**.
 - **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.
 - **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.
 
-![Reminder on an alert group Audit tab](./images/alert-group-audit-reminder.png)
+![The Audit tab of an alert group: a timeline from the group opening through each notification sent, including a reminder and a new instance](./images/alert-group-audit-tab.png)
 
 ### Instances
 

src/content/docs/docs/apm-and-tracing/apm-views/api-monitoring.mdx

@@ -38,6 +38,13 @@ The protocol badge determines what a row can show:
 - **HTTP** rows carry a method chip and a full `2xx`/`3xx`/`4xx`/`5xx` status breakdown.
 - **RPC** rows (gRPC, Connect) have no HTTP method or status classes, so the **Status** column shows a dash (`—`). Judge these endpoints by their **error rate**, which is derived from span status and works for every protocol.
 
+### No route and Unknown method rows
+
+Two kinds of HTTP row group requests that have no endpoint label of their own:
+
+- **No route:** requests the service handled without reporting a route. Typical causes are `404` responses, requests rejected before routing (authentication, CORS preflight `OPTIONS`), and proxies that do not record routes. Each service gets one such row per HTTP method. Open the row to see the individual requests and, where the span records one, their paths.
+- **Unknown method:** requests with a non-standard HTTP method, such as scanner verbs (`PROPFIND`) or request lines the instrumentation could not read. Each service gets one such row.
+
 :::tip
 The trend sparkline rolls up hourly, so it needs at least two hourly buckets to draw a line.
 :::
@@ -75,7 +82,7 @@ At the top, summary tiles show **Requests**, **Error rate**, and **p95 latency**
 
 The drill-down ends with a table of the endpoint's traces, so you can move from a metric to the exact requests behind it:
 
-- Each row shows the start time, span, and duration, with a **View trace** action that opens the full trace in [Trace Detail](../../trace-detail/).
+- Each row shows the start time, the request (its path, or the method name for RPC), the HTTP status, and the duration, with a **View trace** action that opens the full trace in [Trace Detail](../../trace-detail/).
 - Toggle **Failed only** to keep just the errored requests. This uses the same protocol-neutral error definition as the metrics, so it covers HTTP `5xx` and gRPC/Connect errors alike.
 - **Open in Traces** hands the current endpoint and time range to the [Trace Explorer](../../trace-explorer/) for deeper filtering and analysis.
 

src/content/docs/docs/apm-and-tracing/apm-views/service-map.mdx

@@ -12,10 +12,15 @@ You can use it to understand service dependencies, traffic flow, and operational
 
 The map is built from distributed traces, so both sources of tracing feed it:
 
-- **[eBPF monitoring](../../../kloudmate-agent/ebpf-observability/)** captures traces at the kernel level with no code change, so an eBPF-covered service appears on the map on its own — on VMs, hosts, and containers. (On [Kubernetes](../../../kloudmate-agent/auto-instrumentation/kubernetes/), eBPF provides the network topology instead, and traces come from the SDK.)
+- **[eBPF monitoring](../../../kloudmate-agent/ebpf-observability/)** captures traces at the kernel level with no code change, so an eBPF-covered service appears on the map on its own. This works on VMs, hosts, and containers, and for [Kubernetes](../../../kloudmate-agent/auto-instrumentation/kubernetes/) workloads set to **eBPF**.
 - **[Auto-instrumentation](../../../kloudmate-agent/auto-instrumentation/overview/)** and the OpenTelemetry SDK produce traces from inside the application.
 
-Each service becomes a node under its `service.name`, and an edge is drawn wherever one service's trace calls another. A service needs a distinct `service.name` to appear as its own node — the agent gives an eBPF-monitored service the same name it carries once auto-instrumented, so it keeps one identity whether eBPF or the SDK is tracing it.
+Each service becomes a node under its `service.name`, and an edge is drawn wherever one service's trace calls another. A service needs a distinct `service.name` to appear as its own node. The agent gives an eBPF-monitored service the same name it carries once auto-instrumented, so it keeps one identity whether eBPF or the SDK is tracing it.
+
+The map also draws calls where only one side is traced:
+
+- **Calls into an eBPF-monitored service from a caller that sends no telemetry**, such as a script or an uninstrumented service. The caller is named after its Kubernetes workload, or shown as `incoming` when it can't be identified.
+- **Calls to a database.** Databases don't send traces, so the calling service's trace is enough to draw the edge.
 
 ## Overview
 
@@ -25,7 +30,7 @@ Open **APM & Services** and select the **Service map** view. You can also open t
 
 Summary chips count the services, external dependencies, dependencies, services with errors, and erroring edges in the selected time range. A service or dependency counts as erroring when its error rate is 0.05% or higher.
 
-The **Service map** view uses the same time range as the **List** view. Click **Refresh** to reload the map with the latest data, and turn on **Show external dependencies** to add the uninstrumented dependencies your services call, such as databases, queues, and third-party hosts.
+The **Service map** view uses the same time range as the **List** view. Click **Refresh** to reload the map with the latest data, and turn on **Show external dependencies** to add the uninstrumented hosts your services call, such as third-party APIs, message queues, and managed databases outside your cluster. Databases running inside your cluster appear without the switch.
 
 The main area displays the **Service Dependency Graph**. Each service is represented as a node showing its name, protocol, request rate, and average latency. The directed edges between nodes represent the call flow and dependencies between services.
 

src/content/docs/docs/database-monitoring/agent-jobs-and-awr.mdx

@@ -15,12 +15,15 @@ The **Agent jobs** tab lists the SQL Server Agent job runs in the time range, so
 
 Each run shows the job name, its status, when it ran, how long it took, and the message it logged. Expand a run to read the full message.
 
-To collect job runs, turn on the **Agent jobs** coverage for the instance in the agent's database monitoring settings. The monitoring login needs the `SQLAgentReaderRole` role in the `msdb` database:
+To collect job runs, turn on the **Agent jobs** coverage for the instance in the agent's database monitoring settings. The monitoring login needs read access to the job tables in the `msdb` database:
 
 ```sql
 USE msdb;
 CREATE USER [kloudmate] FOR LOGIN [kloudmate];
-ALTER ROLE SQLAgentReaderRole ADD MEMBER [kloudmate];
+GRANT SELECT ON dbo.sysjobs TO [kloudmate];
+GRANT SELECT ON dbo.sysjobhistory TO [kloudmate];
+GRANT SELECT ON dbo.sysjobactivity TO [kloudmate];
+GRANT EXECUTE ON dbo.agent_datetime TO [kloudmate];
 ```
 
 Replace `kloudmate` with your monitoring login. Skip the `CREATE USER` line if the login already has a user in `msdb`.

src/content/docs/docs/database-monitoring/databases-list.mdx

@@ -56,6 +56,6 @@ You can sort by instance name, the query columns, connections, and uptime. Insta
 1. Click **Monitor a database**.
 2. Choose the agent that will monitor the database. The agent must be able to reach the database: install it on the database's own host for a self-hosted database, or on a host with network access to a managed one. Agents in manual configuration mode can't be used here; switch the agent to managed in **Settings** first.
 3. Choose the engine. The list shows the engines that agent supports.
-4. Configure the database in the agent's database monitoring settings, which open with the agent and engine already selected. See [Database monitoring overview](../../kloudmate-agent/database-monitoring/overview/) for the coverages and credentials.
+4. Configure the database in the agent's database monitoring settings, which open with the agent and engine already selected. See [the wizard steps](../../kloudmate-agent/database-monitoring/overview/#the-wizard) for the coverages and credentials.
 
 Data starts arriving within a minute of saving.

src/content/docs/docs/database-monitoring/index.mdx

@@ -12,7 +12,7 @@ The **Databases** page lists every database the KloudMate agent monitors, with i
 
 ## Get your databases onto the page
 
-A database appears on the **Databases** page after you set up monitoring for it in the KloudMate agent. You do this through a wizard: pick the engine, choose what to collect, and give the agent a monitoring user's credentials. See [Database monitoring overview](../kloudmate-agent/database-monitoring/overview/) for the setup, and [Engines and coverages](../kloudmate-agent/database-monitoring/engines-and-coverages/) for what each engine can collect.
+A database appears on the **Databases** page after you set up monitoring for it in the KloudMate agent. You do this through a [wizard](../kloudmate-agent/database-monitoring/overview/#the-wizard): pick the engine, choose what to collect, and give the agent a monitoring user's credentials. See [Database monitoring overview](../kloudmate-agent/database-monitoring/overview/) for the setup, and [Engines and coverages](../kloudmate-agent/database-monitoring/engines-and-coverages/) for what each engine can collect.
 
 What you see on an instance depends on the **coverages** you turned on for it in the wizard. For example, **Top queries** and **Query patterns** need the **Query performance (samples + top queries)** coverage, and **Topology** needs **Replication topology & lag**. When a tab has no data because a coverage is off, the tab tells you which coverage to turn on.
 

src/content/docs/docs/incident-management/index.mdx

@@ -19,6 +19,7 @@ Use Incident Management to organize incident response workflows, route alerts to
 - [Routing Rules](./routing-rules/)
 - [Status Pages](./status-pages/)
 - [Slack Integration](./slack-integration/)
+- [War Rooms](./war-rooms/)
 
 :::note
 **Two features share the name "Routing rules."** The [Routing Rules](./routing-rules/) listed here decide how an incoming alert becomes an incident: which service, escalation policy, and severity it gets, and whether to suppress it. To route alert *notifications* to channels like Slack, see [Alerts → Routing rules](../alerts/routing-rules/) instead.

src/content/docs/docs/incident-management/war-rooms/_meta.json

@@ -0,0 +1,4 @@
+{
+  "label": "War Rooms",
+  "order": 12
+}

src/content/docs/docs/incident-management/war-rooms/index.mdx

@@ -0,0 +1,81 @@
+---
+title: "Incident War Rooms"
+description: "Open a dedicated Slack channel or Microsoft Teams chat for an incident, with the responders already in it and a call link attached."
+sidebar:
+  label: "Overview"
+  order: 1
+---
+
+Some incidents need a room, not another notification. A war room is a Slack channel or a Microsoft Teams group chat that belongs to one incident. KloudMate creates it, invites the responders and the on-call engineers, posts an incident card at the top, and attaches a conference call link.
+
+The card tracks the incident. It shows the current severity and status, and in Slack you can acknowledge, resolve, add responders, and leave a note without opening KloudMate.
+
+An incident gets one room. If a routing rule, a Slack button, and the incident page all ask for a room in the same minute, you still end up with one channel.
+
+## Open a war room
+
+- **From the incident.** Click **Start war room** on the **Incident War Room** panel. You can change the channel name, paste a call link, and invite extra people before it opens.
+- **From Slack.** Click **Start war room** on the incident alert in your shared channel.
+- **From a routing rule.** Turn on **Start War Room** in the rule's actions, and every incident it creates opens with a room.
+- **From an escalation step.** Check **Start War Room on this step**, and the room opens when the incident escalates that far.
+
+Both automatic paths are covered in [Set up war rooms](./setup/#open-a-room-automatically). KloudMate creates the room in the background, so it appears a few seconds after the incident, not instantly.
+
+## What responders see in Slack
+
+The room opens as a private channel by default, and the first message is the incident card.
+
+The card leads with the incident title as a link back to KloudMate, then the severity, status, and service. Below that it lists everyone who was invited. Anyone KloudMate couldn't match to a Slack account is called out under **Could not add**, so you know to pull them in yourself. When the incident has a call link, the card carries a **Join Call** button, and a dial-in number when the call provider gives one.
+
+The channel topic repeats the severity, the title, the link to the incident, and the call link. It's there for whoever joins an hour in and scrolls to the top of nothing.
+
+### Act on the incident from the room
+
+The card's buttons change with the incident:
+
+| Button | What it does |
+|---|---|
+| **Acknowledge** / **Unack** | Acknowledges the incident, or takes the acknowledgement back. |
+| **Resolve** / **Unresolve** | Resolves the incident, or reopens it. |
+| **Add Responders** | Opens a picker of workspace members and attaches them to the incident. Each one is invited to the room. |
+| **Note** | Opens a box for a note. It lands on the incident's **Notes** tab with your name against it. |
+| **Run RCA** | Starts an [AI investigation](/kloudmate-assistant/investigations/) for the incident. |
+
+While an investigation runs, the card reads **RCA Running**. The findings arrive as a reply in the card's thread, with a link to the full investigation, and the card switches to **RCA Complete**. If the investigation stalls, the card reads **RCA Failed** after 15 minutes and **Run RCA** comes back so you can try again.
+
+KloudMate also replies in that thread as the incident moves: acknowledged or unacknowledged, resolved or reopened, assigned or unassigned, escalated, and re-notified, each stamped in UTC. The card and the topic are rewritten in place on every change, wherever the change came from. Resolve the incident in KloudMate and the Slack card follows.
+
+## What responders see in Microsoft Teams
+
+The room is a group chat owned by the Microsoft 365 account you connected. The card shows the same incident facts, the people who were invited, the ones who couldn't be added, and buttons for **Join Call** and **View Incident**. It's rewritten in place as the incident changes, the same as in Slack.
+
+:::note
+Teams rooms don't carry the action buttons, the thread replies, or RCA. Acknowledge, resolve, and add notes from the incident page instead. Teams group chats also have no public or private setting, so **Private room** has no effect on them.
+:::
+
+## The incident alert turns into a pointer
+
+Once a Slack war room exists, the incident alert in your shared channel stops carrying its own buttons and becomes a signpost: **Open war room** and **Open in KloudMate**. It isn't rewritten again after that, so read the room's card for the current state. That keeps the conversation in one place instead of splitting it between the alert thread and the room.
+
+## Follow the room from the incident page
+
+The **Incident War Room** panel on the incident shows the room as **Active** or **Archived**, links to the channel or chat, and lists the members. A member KloudMate couldn't match to a chat account is tagged **Unmapped**, and hovering it tells you why.
+
+**Conference call** sits beside it. Use the edit icon to add or replace the **Meeting link** and the **Dial-in** at any point while the incident is open, and KloudMate updates the card and the topic. A Developer can also end the room early with **Archive war room**, which posts the closing summary and archives the channel straight away.
+
+## When the incident resolves
+
+KloudMate marks the card resolved, then starts the clock on the archive delay, which is one hour unless you've changed it. When the delay runs out, it posts a closing summary and archives the Slack channel. A Teams chat stays in place, because group chats can't be archived, so the closing summary is what tells responders the room is done. Either way the history stays in your chat workspace.
+
+Set the delay to **Keep the room open** if you'd rather archive rooms yourself.
+
+:::caution
+Reopening an incident doesn't cancel an archive that's already scheduled. If you unresolve an incident inside the delay window, the Slack channel is still archived on time, and starting the war room again returns the archived room. Unarchive the channel in Slack to carry on in it.
+:::
+
+## Related
+
+- [Set up war rooms](./setup/): what to connect, which permissions it needs, and the defaults for every room.
+- [Troubleshooting](./troubleshooting/): what to do when a room won't open or opens without a call.
+- [Slack Integration](../slack-integration/): the install that war rooms use, and per-user account linking for ChatOps.
+- [Routing Rules](../routing-rules/) and [Escalation Policies](../escalation-policy/): the two places a room can open on its own.