PR feedback + note on overview page

Author: wajihaparvez

deploy-manage/monitor/autoops/autoops-for-serverless.md

@@ -12,21 +12,25 @@ For [{{serverless-full}}](/deploy-manage/deploy/elastic-cloud/serverless.md) pro
 
 In your {{serverless-full}} project, Elastic ensures that the appropriate resources are adequately provisioned and autoscaled so that your workloads run efficiently. This is why {{serverless-full}} is billed based on the effective usage of compute and storage resources.
 
-:::{note} 
+:::{tip} 
 For more information about how {{serverless-full}} is priced and packaged, refer to the following pages:
 * [{{serverless-full}} pricing page](https://www.elastic.co/pricing/serverless-search)
 * [{{serverless-full}} pricing and packaging blog post](https://www.elastic.co/blog/elastic-cloud-serverless-pricing-packaging)
 :::
 
 Since your monthly serverless bill is directly related to how many resources have been consumed, it's important for you to understand why your consumption fluctuates and how past usage was influenced by your project's performance. This information lets you adapt your workloads accordingly and have better control over your future bills.
 
-This is where AutoOps comes in. With AutoOps for serverless, you can:
+This is where AutoOps comes in. With AutoOps for Serverless, you can:
 
 * understand and monitor your usage patterns through project-level and index-level performance metrics.
 * access several curated dashboards to look at your project from all the different angles.
 * have full visibility into the main serverless billing dimensions.
 
-## AutoOps for serverless billing dimensions
+:::{note}
+To align with the [new {{serverless-full}} architecture](https://www.elastic.co/blog/journey-to-build-elastic-cloud-serverless#rethinking-architecture:-from-stateful-to-stateless), AutoOps for Serverless does not include monitoring API endpoints such as [node statistics](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-nodes-stats) and [cluster statistics](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-stats). These endpoints are included in [](ec-autoops-how-to-access.md) and [](cc-autoops-as-cloud-connected.md).
+:::
+
+## AutoOps for Serverless billing dimensions
 
 AutoOps for serverless focuses on different [billing dimensions](/deploy-manage/cloud-organization/billing/serverless-project-billing-dimensions.md) related to compute and storage, which are explained in the following subsections.
 
@@ -40,7 +44,7 @@ There are three main types of VCUs:
 
 VCUs materialize the load that each of the above tiers has to sustain to respond to your search, indexing, and machine learning needs respectively. As the load of a given tier fluctuates above or below some pre-defined thresholds, the tier will autoscale accordingly to accommodate that load.
 
-:::{note} 
+:::{tip} 
 For more information about how autoscaling works in serverless, refer to the following blog posts:
 * [Search tier autoscaling](https://www.elastic.co/search-labs/blog/elasticsearch-serverless-tier-autoscaling)
 * [Ingest autoscaling](https://www.elastic.co/search-labs/blog/elasticsearch-ingest-autoscaling)

deploy-manage/monitor/autoops/search-ai-lake-view-autoops-serverless.md

@@ -23,7 +23,7 @@ To get to this view, [access AutoOps](/deploy-manage/monitor/autoops/access-auto
 
 Use the following features to explore this view:
 * Use the built-in **project picker** to switch between projects. This allows you to make quick context changes without needing to navigate back to your {{ecloud}} home page to select a different project.
-* Select **custom time windows** let to explore usage data ranging from the last 3 hours to the last 10 days. The charted data is bucketed per day except when you select a period of up to 24 hours, when it is bucketed per hour.
+* Select **custom time windows** to explore usage and performance data up to the last 10 days. The charted data is bucketed per day except when you select a period of up to 72 hours, when it is bucketed per hour.
 
 {applies_to}`elasticsearch:` {{es-serverless}} projects offer the same experience, except that unlike Observability and Security Serverless projects, they only focus on storage retained and not on ingest rate usage metrics.
 

deploy-manage/monitor/autoops/search-tier-view-autoops-serverless.md

@@ -23,7 +23,7 @@ On the **Search Tier** page, the top half of the screen offers general insights
 
 Use the following features to explore this view:
 * Use the built-in **project picker** to switch between projects. This allows you to make quick context changes without needing to navigate back to your {{ecloud}} home page to select a different project.
-* Select **custom time windows** let to explore usage and performance data ranging from the last 3 hours to the last 10 days. The charted data is bucketed per day except when you select a period of up to 24 hours, when it is bucketed per hour.
+* Select **custom time windows** to explore usage and performance data up to the last 10 days. The charted data is bucketed per day except when you select a period of up to 72 hours, when it is bucketed per hour.
 * Explore different **visualizations** presenting the trend of search VCU usage over time and how it compares to the performance of the search tier in terms of search rate and latency.
 * View the **annotations** overlaying the search VCUs usage chart to understand when the search power and boost window changed during the selected time period and how that might have affected the autoscaling of your project (and consequently your VCU consumption). 
 * Gain insights from the **performance charts** depicting search rate and search latency trends to understand why your VCU consumption might fluctuate over time. 
@@ -43,7 +43,7 @@ Each row of the table represents a single index or data stream and provides the
 * The latest **search latency** in the selected time period.
 * The timestamp of the **last search** on the index or data stream.
 
-Using this table, you can detect which of your indices or data streams are currently being searched and at what rate and latency. This helps you identify which indices are suffering from search pressure, so that you can deduce where that load is coming from manage it to optimize your search VCU consumption.
+Using this table, you can detect which of your indices or data streams are currently being searched and at what rate and latency. This helps you identify which indices are suffering from high [search load](https://www.elastic.co/search-labs/blog/elasticsearch-serverless-tier-autoscaling#what-is-search-load?), so that you can deduce where that load is coming from and manage it accordingly.
 
 For historical analysis, you can also expand each row to reveal performance trends over time, helping you detect patterns or anomalies in search performance for each index and data stream individually.
 
@@ -61,7 +61,7 @@ The consumption of search VCUs is directly related to autoscaling. When your pro
 The following factors may cause upscaling or downscaling and consequently an increase or decrease in the number of search VCUs consumed:
 
 ### Search rate
-A higher search rate will lead to a larger search load, which means the project will be upscaled and more search VCUs will be consumed. Similarly, a smaller search load means fewer search VCUs being consumed.
+A higher search rate will lead to a larger [search load](https://www.elastic.co/search-labs/blog/elasticsearch-serverless-tier-autoscaling#what-is-search-load?), which means the project will be upscaled and more search VCUs will be consumed. Similarly, a smaller search load means fewer search VCUs being consumed.
 
 The search rate on your project can increase for many different reasons, such as when more clients start issuing search requests at the same time, or when a complex dashboard with many visualizations is configured with a low auto-refresh rate.