diff --git a/docs/open360/alerts/configure-alerts-explore.md b/docs/open360/alerts/configure-alerts-explore.md
index aa9f86bd..ce85d9dc 100644
--- a/docs/open360/alerts/configure-alerts-explore.md
+++ b/docs/open360/alerts/configure-alerts-explore.md
@@ -18,6 +18,15 @@ Community plans limit the number of alerts that may be enabled. See the official
You cannot configure alerts using the `logzio-alert` log type. This type is ignored by the alerts engine.
:::
+### Choose the alert type
+
+An alert watches either logs or metrics, and you pick which when you name it:
+
+* **Log alert** — a Lucene query over your log data. This is the default and what the rest of this page describes.
+* **Metrics alert** — a PromQL query over your metrics. Currently marked **Beta**.
+
+The type determines the query editor you get, so switch it before writing the query rather than after. For metrics alerts, see [Metrics alerts](#metrics-alerts) below.
+
### Name the alert
Give your alert a meaningful name. When your alert triggers, its name is used as the email subject or notification heading.
@@ -94,6 +103,28 @@ You can set the trigger condition time frame between 5 minutes and up to 24 hour
+### Metrics alerts {#metrics-alerts}
+
+A **Metrics alert** watches a PromQL query instead of a Lucene one. The rest of the form — scheduling, recipients, severity, metadata, AI analysis — works the same way.
+
+For each query you set:
+
+* **Data source** — which metrics datasource to query. Select it before writing the query, since it determines what's available.
+* **PromQL** — the expression to evaluate. Syntax is validated, so a malformed query is reported as you write rather than silently never firing.
+
+You can add up to **5 queries** to one metrics alert, and combine them with a **math expression** — which is how you alert on a ratio rather than an absolute number. An error rate, for example, is failures divided by total, and that's an expression over two queries rather than a single one.
+
+Two ways to skip writing the query by hand:
+
+* **From Explore** — build the query in the [Metrics tab](/docs/open360/explore/explore-metrics/), then use **Create alert** from the actions menu. The PromQL comes with you.
+* **From a dashboard panel** — a panel that already shows the thing you want to watch can be turned into an alert, pre-filled from its query. See [Dashboards Configuration Guide](/docs/open360/dashboards/edit-dashboards/) for the eligibility rules.
+
+Proving the query returns what you expect in Explore first, then promoting it to an alert, is considerably faster than debugging an alert that never fires.
+
+:::note
+Metric alerts created here don't appear under Open Source Apps → Metrics → Alert Rules. The two systems are managed separately.
+:::
+
### Configure alert scheduling
You can use the scheduling mechanism to manage the trigger condition frequency.
@@ -187,6 +218,19 @@ Once triggered, the AI Agent will analyze related logs, metrics, and patterns. A
AI Agent Analysis runs **once every hour**.
:::
+#### Recipients for the analysis
+
+By default the analysis goes to the same recipients as the alert itself. You can instead select recipients manually, which is worth doing when the analysis is for a different audience than the page — for example the owning team gets the alert, while a shared channel gets the write-up.
+
+#### Runbook and instructions
+
+Alongside the analysis you can attach a **runbook** and **instructions**. Both are context the analysis draws on as well as guidance for whoever picks the alert up, so they do double duty:
+
+* **Instructions** — what the responder should do. Also see [Alert Instructions](/docs/open360/alerts/instructions/).
+* **Runbook** — the procedure to follow, for alerts with an established response.
+
+An alert with a clear description, instructions and a runbook produces a noticeably more useful analysis than a bare query, because the model has something to reason against beyond the raw data.
+
[Learn more about AI Agent Analysis](/docs/user-guide/observability/ai-agent-analysis/).
Select alert's output format & content
diff --git a/docs/open360/alerts/intro-alerts.md b/docs/open360/alerts/intro-alerts.md
index b73f3f1a..db320ac3 100644
--- a/docs/open360/alerts/intro-alerts.md
+++ b/docs/open360/alerts/intro-alerts.md
@@ -40,6 +40,24 @@ Click on the corresponding column header to filter alerts chronologically by **n
+Alerts has two tabs: **Configurations** for the alerts you've defined, and **Status** for what has actually fired.
+
+On the Configurations tab, each alert shows whether it came from logs or metrics, its **Name**, **Severity**, **Tags**, **Created By**, **Last Modified**, and an **Active** toggle.
+
+The **Active** toggle turns an alert off without deleting it — the right move for an alert that's noisy during a migration or a known incident, since you keep its configuration and history.
+
+Severity is one of Info, Low, Medium, High or Severe.
+
+:::note
+Users with read-only permissions can view alerts but not create, edit or delete them, so the editing controls described below won't appear for them.
+:::
+
+To see what has actually fired rather than what's configured, switch to the [Status tab](/docs/open360/alerts/triggered-alerts/).
+
+:::note
+Metric alerts created here don't appear under Open Source Apps → Metrics → Alert Rules. The two are managed separately.
+:::
+
### Manage Log alerts
You can manage alerts individually or in bulk.
diff --git a/docs/open360/alerts/triggered-alerts.md b/docs/open360/alerts/triggered-alerts.md
new file mode 100644
index 00000000..25453b27
--- /dev/null
+++ b/docs/open360/alerts/triggered-alerts.md
@@ -0,0 +1,58 @@
+---
+sidebar_position: 6
+title: Triggered Alerts
+description: Review and work through alerts that have fired in Logz.io - filter them, read their instructions, and see the AI analysis.
+image: https://dytvr9ot2sszz.cloudfront.net/logz-docs/social-assets/docs-social.jpg
+keywords: [logz.io, alerts, triggered alerts, alert events, severity, incident response, on call, rca, observability]
+---
+
+Creating alerts is half the job. The **Status** tab under Alerts is the other half: what actually fired, how severe it was, and what you're supposed to do about it.
+
+Alerts has two tabs — **Status** for what has triggered, and **Configurations** for the alerts you've defined. This page covers Status; for Configurations see [Understanding Alerts](/docs/open360/alerts/intro-alerts/).
+
+
+
+## Read the list
+
+| Column | What it tells you |
+|---|---|
+| Source icon | Whether the alert came from logs or metrics. |
+| **Name** | The alert that fired. |
+| **Group** | The group-by values this trigger is for, one chip per field — for example `env_id`, `k8s_pod_name`, `k8s_namespace_name`. Extra fields collapse into a `+n` chip. |
+| **Severity** | Info, Low, Medium, High or Severe. |
+| **State** | **Triggered** while the condition holds, **Resolved** once it clears. |
+| **Tags** | The alert's tags, for filtering by team or system. |
+| **Time** | How long ago it last triggered. |
+
+The **Group** column is the one people overlook. An alert grouped by pod produces a separate trigger per pod, so the list tells you *which* pod is unhealthy without opening anything.
+
+A count above the list shows how many triggered alerts match, and the list is paginated with a rows-per-page control — useful, because a noisy hour produces more rows than you'd expect.
+
+## Narrow the list
+
+Alongside a **Search by name** box, you can filter by:
+
+* **Source** — logs or metrics
+* **Severity**
+* **Tags**
+* **State** — for example, only what's still Triggered rather than already Resolved
+* **Time range**
+
+Filtering by State to hide Resolved is usually the first thing worth doing during an incident, since it separates what's still broken from what already recovered.
+
+## Work a triggered alert
+
+Selecting a triggered alert opens its detail, with the data that caused it and the context you need to act.
+
+Row actions include **View Instructions** — the guidance whoever created the alert wrote for whoever receives it. If your alerts don't have instructions, that's the highest-value thing you can add to them; see [Alert Instructions](/docs/open360/alerts/instructions/).
+
+## AI analysis
+
+Where an alert has AI analysis enabled, the list shows its status and you can open the generated root-cause analysis alongside the trigger, rather than starting your investigation from scratch. See [Configure an Alert](/docs/open360/alerts/configure-alerts-explore/) for how to turn it on.
+
+## Related
+
+* [Understanding Alerts](/docs/open360/alerts/intro-alerts/)
+* [Configure an Alert](/docs/open360/alerts/configure-alerts-explore/)
+* [Alert Instructions](/docs/open360/alerts/instructions/)
+* [Set Alert Triggers](/docs/open360/alerts/alert-triggers/)
diff --git a/docs/open360/data-hub/warm-tier.md b/docs/open360/data-hub/warm-tier.md
new file mode 100644
index 00000000..da7dbefa
--- /dev/null
+++ b/docs/open360/data-hub/warm-tier.md
@@ -0,0 +1,41 @@
+---
+sidebar_position: 9
+title: Warm Tier
+description: How warm-tier data behaves in Logz.io Open 360 - searching it from Explore, using it on dashboards, and why results need an explicit Run Query.
+image: https://dytvr9ot2sszz.cloudfront.net/logz-docs/social-assets/docs-social.jpg
+keywords: [logz.io, warm tier, data tiers, retention, storage, explore, dashboards, cost optimization, observability]
+---
+
+Warm tier keeps older logs searchable at a lower cost than your primary retention. This page covers how warm-tier data behaves when you use it; for what the tier is and how to set it up, see [Warm Tier](https://docs.logz.io/docs/user-guide/admin/data-tiers/warm-tier/).
+
+The practical thing to know is that warm-tier searches are **deliberate rather than automatic**.
+
+## Searching warm data in Explore
+
+When your selected timeframe reaches into warm-tier data, [Explore](/docs/open360/explore/new-explore/) stops re-running the query as you change things. Instead you'll see:
+
+> Current results are outdated — Click **Run Query** to apply new search
+
+This is intentional. Warm-tier queries are heavier than hot-tier ones, so Explore doesn't fire one off every time you adjust a filter or a column. You compose the search you want, then run it.
+
+If results look stale after you've changed something, that banner is why. Select **Run Query**.
+
+## Warm data elsewhere
+
+* **CSV export** — exports include warm-tier data when your timeframe covers it, so you don't need a separate route to get older logs out.
+* **Accounts** — warm tier is configured per account; see the account management docs for enabling and sizing it.
+
+:::note
+Dashboards don't support warm-tier data. Panels query your primary retention only, so a dashboard won't show warm data even when its time range covers it — use Explore for that.
+:::
+
+## Practical notes
+
+* Narrow the timeframe before you narrow anything else. On warm data, a smaller window is the difference between a query you wait on and one you don't.
+* Expect warm queries to take longer than hot ones.
+
+## Related
+
+* [Warm Tier setup](https://docs.logz.io/docs/user-guide/admin/data-tiers/warm-tier/)
+* [Data tiers overview](https://docs.logz.io/docs/user-guide/admin/data-tiers/data-tiers-intro/)
+* [Cost optimization](/docs/open360/data-hub/cost-optimization/)
diff --git a/docs/open360/global-search.md b/docs/open360/global-search.md
new file mode 100644
index 00000000..6aa6d8b2
--- /dev/null
+++ b/docs/open360/global-search.md
@@ -0,0 +1,46 @@
+---
+sidebar_position: 9
+title: Global Search
+description: Find pages, saved searches, dashboards and alerts across Logz.io from one search box.
+image: https://dytvr9ot2sszz.cloudfront.net/logz-docs/social-assets/docs-social.jpg
+keywords: [logz.io, global search, search, navigation, saved searches, dashboards, alerts, open 360, observability]
+---
+
+Global search finds things across your account from the search control in the top bar — pages, saved searches, dashboards and alerts, without you having to remember which section each lives in.
+
+It's the fastest way to reach a dashboard whose exact name you've half-forgotten, and it beats navigating by menu once an account has more than a handful of saved objects.
+
+## Open it with a shortcut
+
+Press **Ctrl + K** to open global search from anywhere in the product.
+
+Note that it's `Ctrl` on every platform, including macOS — `Cmd + K` won't open it.
+
+The shortcut also works while you're inside the embedded open-source apps, such as OpenSearch Dashboards and Grafana, so you don't have to click out of them first to go somewhere else.
+
+## What it searches
+
+Results are grouped by where they came from:
+
+| Group | What's in it |
+|---|---|
+| **Pages** | Product pages and settings screens — a way to jump straight to a page by name. |
+| **Explore saved searches** | Saved searches from [Explore](/docs/open360/explore/new-explore/). |
+| **Unified dashboards** | Your [Unified Dashboards](/docs/open360/dashboards/dashboards-hub/). |
+| **OpenSearch Dashboards** | Saved objects from OpenSearch Dashboards. |
+| **Logs alerts** | Log alert definitions. |
+| **Metrics** | Metrics objects and alerts. |
+| **Other** | Anything that doesn't fall into the groups above. |
+
+Each group is labelled with its own icon, so you can tell a dashboard from a saved search from an alert at a glance rather than reading every result.
+
+## Filtering results
+
+Use the filter control to restrict the search to particular groups. When a filter is active it's indicated on the control, so you don't spend time wondering why an object you know exists isn't appearing.
+
+That's worth knowing because it's the most common source of confusion: a filtered search that looks like a missing object.
+
+## Notes
+
+* Each source is searched independently with its own timeout, so a slow or unavailable source doesn't hold up the rest of the results. A group can therefore come back empty because it timed out rather than because it had no matches — searching again usually resolves it.
+* Results respect your permissions and the account you're currently in. Switching accounts changes what global search can find.
diff --git a/docs/open360/settings/ai-settings.md b/docs/open360/settings/ai-settings.md
new file mode 100644
index 00000000..a85449f0
--- /dev/null
+++ b/docs/open360/settings/ai-settings.md
@@ -0,0 +1,35 @@
+---
+sidebar_position: 1
+title: AI Settings
+description: Set monthly limits on Logz.io AI usage and review your AI subscription from Plan and usage.
+image: https://dytvr9ot2sszz.cloudfront.net/logz-docs/social-assets/docs-social.jpg
+keywords: [logz.io, ai settings, ai usage, ai limits, capping, plan and usage, billing, orioniq, observability]
+---
+
+AI features consume usage that's billed, so Logz.io gives you a place to cap it. **AI Settings** lives under **Settings → Plan and usage** and does two things: sets monthly limits, and shows your AI subscription details.
+
+Find it before you roll AI features out to a team, not after.
+
+## Set monthly limits
+
+Two limits can be set independently, each with its own on/off toggle:
+
+| Limit | Caps |
+|---|---|
+| **Chat** | AI chat usage |
+| **Invocations** | Agent invocations |
+
+Turn a limit on and enter a monthly value; leave it off and the limit reads **No limit set**. A limit must be zero or greater — setting `0` is valid and effectively disables that kind of usage rather than being rejected as invalid.
+
+Saving confirms with *AI monthly limits updated*.
+
+Limits are monthly, so they reset on your billing cycle rather than rolling continuously.
+
+:::note
+AI Settings is being rolled out. If you don't see it under Plan and usage, it isn't enabled for your account yet — contact [Logz.io support](https://logz.io/support-page/).
+:::
+
+## Related
+
+* [Plan and usage](https://docs.logz.io/docs/user-guide/admin/logzio-accounts/plan-and-usage/)
+* [AI Agent FAQ](/docs/open360/observability/faq/)
diff --git a/static/img/open360/triggered-alerts.png b/static/img/open360/triggered-alerts.png
new file mode 100644
index 00000000..21ff9a88
Binary files /dev/null and b/static/img/open360/triggered-alerts.png differ